fix(wcs): reject negative slice start in WCS.slice - #20323

Small comment below, this is ok otherwise

The following review comment was generated by Claude Fable, and I agree with the points raised (I suggested some of them)

Thanks! This is the same situation as #20320 though, so I would apply the same reasoning here: rather than rejecting negative starts unconditionally, we should support them properly when the shape is known and only raise when it is not. The case is even stronger on this path, because WCS.slice already uses the shape to resolve negative stops correctly, via nitems = len(range(self._naxis[wcs_index])[iview]) a few lines below your check. The only thing actually broken when _naxis is known is the crpix/distortion-shift arithmetic: today wcs[:, :, -30:] on a WCS with pixel_shape = (100, 100, 50) produces the correct _naxis of 30 but shifts crpix by +30 instead of -70, so the returned WCS is internally inconsistent rather than obviously wrong. So instead of the up-front loop, I would normalize each slice per axis just before the crpix arithmetic:

n = self._naxis[wcs_index]                                                                                                                                                   
if n > 0:
    iview = slice(*iview.indices(n))
elif iview.start is not None and iview.start < 0:
    raise IndexError(
        "Negative indices are not supported when slicing a WCS with unknown shape (NAXIS not set)."                                                                          
    )

slice.indices(n) returns a non-negative start/stop and preserves the step, so it should compose with the existing downsampling branch (negative steps are already rejected earlier), and since the SIP crpix and distortion table crval shifts all use iview.start, normalizing before the arithmetic fixes them in the same place. For a header-derived WCS, NAXIS* is set, so wcs[-6:, -6:] would then slice the WCS the same way numpy slices the data, and the error only remains for WCS objects that genuinely
have no shape information.

One more reason to keep the two PRs in sync: as soon as the view contains an integer index (e.g. wcs[0, -6:]), slice silently reroutes to SlicedFITSWCS, i.e. the code path #20320 touches. If the two adopt different policies, the same slice will behave differently depending on whether a dimension is dropped, so whatever we converge on there (see my
comment on that PR) should be mirrored here with the same semantics and error message.

For tests, I would add: negative start with pixel_shape set gives results identical to the equivalent positive slice (including crpix and array_shape); negative start without shape information raises IndexError; and a case with a SIP or distortion-corrected WCS to confirm the auxiliary shifts come out right.

Note the phrase "see my comment on that PR" assumes the #20320 comment is posted first (or around the same time) — post them in that order, or drop the parenthetical if you only comment here.