Fix server error when downloading shared data with nothing selected

[DKilkenny]

Fixes #1631

Choosing "download" on the share form builds an astropy Table from a list of row dicts. When the selection is empty that list is empty, so the table has no columns at all, and table.sort(['timestamp']) raises ValueError: {'timestamp'} is not a subset of table columns. That surfaces as a 500, which is the traceback in the issue.

It turns out this isn't specific to FITS files, or to data products at all. Two routes reach DataShareView: dataproducts:share from the data product list, and dataproducts:share_all from the target photometry list. The share-box checkboxes that fill the selection are only rendered in photometry_datalist_for_target.html, so on the data product page the selection is always empty and download fails every time regardless of what the file is. The reporter's URL, /dataproducts/data/3/share/, is that route. The photometry page fails the same way if you submit without ticking anything.

Both cases have the same cause, so there's one guard for them. download_data() now returns None when the selection matches no photometry, and the view reports that with messages.error instead of raising. sharing_feedback_handler moved inside the else branch, which looks like an unrelated change but isn't: the download branch used to return unconditionally so it could never reach that call, and without the move response would be unbound on the new path.

There's a second half I deliberately left alone. download_data ignores product_id entirely, so "download" on a data product can't do what the button implies even once it stops erroring. Whether that option should be removed from that form (get_sharing_destination_options(include_download=False) already exists) or should stream the file instead felt like that was the team's call. Happy to fix if you want

Testing

Three tests added to TestShareDataProducts, covering the empty selection on both routes and the normal case still downloading. Both empty-selection tests fail with the original ValueError when the two source files are reverted to dev, so they genuinely guard the bug rather than passing on their own. The CSV test asserts on parsed rows rather than raw substrings, because a timestamp like 21:47:17.512345 contains a brightness-looking 17.5.