Fix table.limit / Bad limit on large datasets (0.0.3)

[fnaji]

Summary

• Server caps a single TableSchemaService.select() at 1,600,000 rows (sci_api_service/lib/src/service/impl/table_schema_service.dart:531). The single-shot ctx.select(names: ['.ci','.ri','.y']) in TercenGridService._getTercenData rejected any plate big enough to exceed that, surfacing as {statusCode: 400, error: table.limit, reason: Bad limit} in the operator UI with the data step hanging on prod.
• Page the main-table select() at 1M rows per call and feed each chunk directly into the existing dataMap. Removes the now-redundant single-shot parse block.
• cselect() / rselect() left untouched — dimension tables (number of spots, number of variables) never approach the cap and only the main-table call appears in the failing prod logs.
• Version bump 0.0.2 → 0.0.3, refreshed build/web/ via flutter build web --wasm, tag 0.0.3 pushed alongside the branch.

How it was found

Investigated a bionavigator data step (bionavigator.pamgene.com/.../ds/858cdbac-3345-446c-b399-99545cc4410d/wa) that 'never finishes'. Prod logs (tercen-prod namespace, 2026-05-21) showed repeated ServiceError({statusCode: 400, error: table.limit, reason: Bad limit}) from TableSchemaService.select matching the operator's UI error toast minified:hP({statusCode: 400, error: table.limit, reason: Bad limit}).

Branching note

Branched off pamgene/pamsoft_grid_flutter_operator tag 0.0.2 (the version pinned by Tercen's operator manifest in prod, per the urls field in operator.json). tercen/master has divergent history with only 0.0.1; this PR brings the fix to tercen/ so the operator's declared upstream actually carries it.

Test plan

• flutter analyze lib/implementations/services/tercen_grid_service.dart — 0 errors, 0 warnings; only pre-existing avoid_print lints
• flutter build web --wasm — succeeds (47s)
• End-to-end on prod: install 0.0.3, re-open Dora's stuck data step, verify regrid loads and Run completes
• Spot-check a small dataset (<<1M rows) to confirm single-chunk path is unchanged in behavior

🤖 Generated with Claude Code

[fnaji]

Updated the build artifacts. Force-pushed fix/table-limit-pagination and re-tagged 0.0.3.

Rationale: my initial 0.0.3 was built with flutter build web --wasm (per VERSION_SYNC.md). That produced a dart2wasm + skwasm bundle, whereas the deployed 0.0.2 was actually dart2js + canvaskit only — the previous 0.0.2 tag never re-ran flutter build web (its build/web/version.json still reads 0.0.1). The mismatch caused Image.memory(...) bitmap rendering to fail in the operator UI ("Failed to load image") even though the table data fetch (the actual fix) was working — confirmed in prod, see screenshot of the grid rendering with 0.0.3.

Rebuilt with plain flutter build web (no --wasm) so the compile target matches what was deployed at 0.0.2. Only build/web/ artifacts changed; lib/, pubspec.yaml, and the tag message are unchanged from the previous push.

[fnaji]

Rebased onto tercen/master and re-tagged 0.0.3. The branch now sits on top of db3a7d4 ("Stream ZIP entries on demand instead of downloading the full archive") instead of the pamgene 0.0.2 snapshot it was branched from before.

This is purely about bringing forward Alex's streaming-fetch refactor — the table-limit pagination patch in tercen_grid_service.dart is byte-identical to the previous push (the two branches had identical tercen_grid_service.dart, so the patch reapplied cleanly with no conflicts).

History on the branch now reads:

e40c77a  Fix table.limit / Bad limit on large datasets    ← this PR
db3a7d4  Stream ZIP entries on demand …                   ← already on tercen/master
7b888e9  Fix: Use actual inner dimensions …               ← common ancestor with pamgene/0.0.2

0.0.3 therefore carries both the streaming-fetch improvement (1× metadata fetch + per-TIFF streaming, no 65 MB upfront ZIP download) and the table-limit pagination fix. build/web/ rebuilt with plain flutter build web (dart2js + canvaskit, no --wasm) to keep the renderer target identical to what 0.0.2 deployed.