TGO CaSSIS spiceinit fails on recent observations: the SPK kernel database omits the reconstructed ephemeris

**ISIS version(s) affected**: 10.0.0

**Description**

spiceinit fails on recent TGO CaSSIS observations with "No instrument position available", even with a fully up-to-date ISISDATA. The cause is in the distributed TGO SPK kernel database (tgo/kernels/spk): it indexes only the predicted spacecraft-position kernels and omits the reconstructed ones, even though the reconstructed kernel files themselves are shipped and present on disk.

Background on the TGO SPK families, which are grouped by quality:

- em16_tgo_fsp_* are the reconstructed spacecraft-position kernels, the accurate final orbit-determination ephemeris. ISIS records them as Type = Reconstructed. This is the family spiceinit needs for a given observation.
- em16_tgo_fap_* (and fcp, flp, fmp, fpp) are predicted, generated ahead of time. ISIS records them as Type = Predicted.

The shipped SPK database (kernels.????.db) contains only the predicted families and zero em16_tgo_fsp entries. So spiceinit cannot select a reconstructed position, and the predicted kernels do not cover recent observations, which gives the "No instrument position" error. That the reconstructed kernel is present and valid is confirmed by ALE isd_generate, which reads the same observation successfully, because its per-observation metakernel lists the em16_tgo_fsp SPK directly rather than going through the ISIS kernel database. So this is a database-indexing gap, not a missing or bad kernel.

**How to reproduce**

Ingest a recent CaSSIS framelet (observation MY36_016378_162_1, acquired 2021-07-25), then:

```
spiceinit from=framelet.cub web=false
# **ERROR** No instrument position available

spiceinit from=framelet.cub web=true
# **ERROR** An error occurred when talking to the server. The server
# encountered an unexpected error.
# (reconstructed positions are not served by web spice for this observation;
# the confusing web-spice message is issue #5946)
```

The reconstructed SPK covering the observation, em16_tgo_fsp_204_01_20210719_20220101_v01.bsp, is present in tgo/kernels/spk, but the shipped kernels.????.db has no em16_tgo_fsp entries.

**Possible Solution**

Regenerate and distribute the TGO SPK database so it indexes the reconstructed em16_tgo_fsp kernels (as Type = Reconstructed) alongside the predicted families, using the standard kerneldbgen procedure:

```
cd $ISISDATA/tgo/kernels/spk
kerneldbgen \
to = '$tgo/kernels/spk/kernels.????.db' \
type = SPK \
recondir = '$tgo/kernels/spk' \
reconfilter = 'em16_tgo_fsp_*.bsp' \
predictdir = '$tgo/kernels/spk' \
predictfilter = 'em16_tgo_fap_*.bsp' \
lsk = '$base/kernels/lsk/naif????.tls'
```

The predicted filter should cover the full set of predicted families the data area currently ships, not just fap. CaSSIS is listed as an automatically-updated mission, so the distributed database should include the reconstructed positions.

Tested: after regenerating the database this way, spiceinit web=false succeeds on the observation above and selects the reconstructed em16_tgo_fsp_204 position, and campt then returns a valid ground point for the image (Planetocentric latitude 18.65 deg, positive-east longitude 77.42 deg, at sample 1024 line 140, which is in the Jezero region as expected).

**Sample test data**

[cassis_MY36_016378_162_1_framelet_10x10.zip](https://github.com/user-attachments/files/30104985/cassis_MY36_016378_162_1_framelet_10x10.zip). This is a CaSSIS cub file that needs to be unizpped.

**Additional context**

Related issues:

- #5946: spiceinit web=true returns a confusing server error when kernels are unavailable (reproduced here on web=true).
- #5512: spiceinit fails on recent CaSSIS images (there, an incomplete kernel download).
- #2642: kerneldbgen selecting kernels by SPICE segment rather than interval caused CaSSIS spiceinit errors.

This report, the diagnosis, and the tested fix were produced with Claude, an AI assistant.