Enhance catalog assertions in ICD tests

[markccchiang]

Description

This PR addresses part of issue #3. The three catalog tests drive filtering, sorting, and progressive loading against a live backend, but none of them looked at the rows that came back. This branch asserts the returned data, fixes the assertions that could not fail, and moves the shared helpers into MyClient.ts.

Per-test summary

CATALOG_FITS_VOT

The filter request streams 918777 rows as 10 messages. The test kept slice(-1)[0] and printed the rest to the console, so the chunk count, the per-chunk sizes, and the row offsets were unchecked.

The whole sequence is now asserted: every message reports the requested catalog and the full filtered table, the chunks tile the subset without a gap or an overlap, every column carries one value per row of its subset_data_size, and the progress rises and reaches 1 only in the last message.

Those are the fields the frontend depends on; AppStore.ts:2381 routes a chunk to a catalog store by fileId, and CatalogProfileStore.ts:98-100 derives the row offset from subsetEndIndex - subsetDataSize. With two catalogs open at once, a wrong fileId writes one table's rows into the other's widget.

Also added: preview_data holds 50 rows of all 62 columns, and the headers describe every column exactly once with no UnsupportedType. The stale description fixture, which the backend does not emit and which nothing asserted, is replaced by the composed string it does emit.

CATALOG_GENERAL

This is the test that covers filtering and sorting, and it verified neither. Four steps issue a sort, a numeric filter, a string filter, and both plus a sort, then assert row counts. The step named "Sorting" checked nothing about order.

The filter and sort name a column while the response keys its columns by index, so the test now ties the two together through the headers and reads the values:

• The returned RA_d values are in ascending order.
• Every returned RA_d is >= 160, and the count equals the number of rows of the unfiltered table which meet that condition.
• Every returned OTYPE_S contains the substring "Star", and the number of returned rows equals the number of rows of the unfiltered table that do.
• Both filters hold at once, the values are sorted, and the combination keeps fewer rows than either filter alone.

CATALOG_LARGE

Part 2 loads three windows of 50 rows at start indices 50, 100, and 150 and asserts only the sizes and indices derived from those start indices. Returning the same 50 rows three times would have passed.

Each window is now compared against the rows the whole-table load of part 1 returned at the same position in the table. That is the actual pagination contract: the frontend fills one allocated array from either path and has to get identical data. The three windows are also asserted to differ from each other; a window ends at subset_start_index + subset_data_size, and filter_data_size stays at the full table size whichever window is requested.

Rows are compared as raw payload rather than decoded values, so the comparison covers every column type. ProtobufProcessing cannot be used because its 64-bit branches need the undefined CARTACompute WASM global.

Checklist

For the pull request:

• Documentation has been updated (or no documentation changes are needed)