WASM 1.7.0 release artifact lacks usable naifspice signature table

## Summary

The official SpiceQL 1.7.0 prebuilt WASM release does not contain a usable `naifspice_sigs.json` in the Emscripten `.data` filesystem image. This breaks the raw `naifspice` loader and also causes the high-level local `getTargetStates` path to fail in the browser.

## Environment

- SpiceQL release: 1.7.0
- Release archive: `spiceql-wasm-1.7.0.zip`
- Browser: Firefox Developer Edition, macOS arm64
- Static Vite server at `http://127.0.0.1:5173`
- Kernels: `naif0012.tls`, `de432s.bsp`, `pck00011.tpc`

Release archive SHA-256:

```text
5517ed41ed9b512991642f0afd34634e7cfc0cbe4a6401d595484b35aede3859
```

## Reproduction

1. Keep the five release browser artifacts co-located.
2. Load `spiceql.js` and call `loadSpiceQL()`.
3. Mount and load the three kernels above.
4. Use `searchKernels:false`, `useWeb:false`, and explicit VFS `kernelList` paths.
5. Call `getTargetStates([et], 399, 0, 'J2000', 'NONE', opts)`.

The browser reports:

```text
Error: [json.exception.parse_error.101] parse error at line 1, column 1:
syntax error while parsing value - invalid literal; last read: '<'
```

Calling the optional raw wrapper independently fails at `loadNaifspice()`:

```text
SyntaxError: Unexpected end of JSON input
```

The wrapper reads the expected path:

```text
/spiceql/SpiceQL/naifspice_sigs.json
```

## Evidence against a transport or kernel-path problem

Browser instrumentation captured HTTP 200 for the WASM and all three kernel fetches, with no REST/query request. The VFS contained:

```text
/kernels/naif0012.tls 5257 bytes
/kernels/de432s.bsp 10895360 bytes
/kernels/pck00011.tpc 131226 bytes
```

## Source-build comparison

Building the exact official `1.7.0` tag from source with the documented toolchain succeeded without source edits:

- Emscripten 3.1.58
- Binaryen 117
- CSPICE 67
- official declared git submodules

The official `bindings/wasm` test suite passed 45/45. The generated build produced a valid 379,421-byte `naifspice_sigs.json`, and its `.data` build command explicitly preloaded it at `/spiceql/SpiceQL/naifspice_sigs.json`.

The source-built runtime then succeeded in the same browser proof:

- deterministic UTC to ET;
- finite Earth SPK state in km and km/s relative to SSB, J2000, NONE;
- finite `J2000` to `IAU_EARTH` matrices with determinant approximately +1;
- orientation changed after one day.

This suggests the release archive's `.data` file is stale, incomplete, or mismatched with the generated wrapper/WASM. The release workflow appears to package `spiceql_wasm.js`, `spiceql_wasm.wasm`, and `spiceql_wasm.data` from the build output, so the missing generated data may originate in the release artifact generation/upload step.

Could the release artifact be regenerated or the packaging workflow checked for the missing signature table? I have not modified SpiceQL internals or filed a PR.

Start with the bindings/wasm test suite and the release workflow that packages spiceql_wasm.js, spiceql_wasm.wasm, and spiceql_wasm.data. Compare the official archive with the source-built .data image, including /spiceql/SpiceQL/naifspice_sigs.json. Done means a regenerated release passes the browser reproduction and includes a usable signature table.

Written by the indexing model from the issue text.