Improve study startup assignment performance

[JackWilb]

What

• Replace normal-startup sequence-assignment collection scans with stable sequence and creation indexes.
• Allocate indexes with a Firestore transaction, a versioned Supabase compare-and-swap counter, and a serialized local-storage operation.
• Preserve rejected-slot reuse, including a bounded legacy fallback for old assignments without index metadata.
• Reuse the prefetched sequence array and modes document during Shell initialization.
• Use a single assignment lookup for completion status.
• Skip the redundant stored-config download when the active config hash is unchanged.
• Narrow Supabase startup verification from select-all to the connect row.

Why

Profiling issue #1176 showed that a fresh participant could scan the complete assignment collection three times: twice while choosing a sequence and once while checking completion. The startup path also downloaded the persisted 1000-row sequence array twice, fetched modes twice, downloaded an unchanged config, and asked Supabase for every study row during verification. These costs grow with study history and provider latency.

Impact and risk

New assignments persist zero-based sequenceIndex and creationIndex metadata. Existing studies require no migration: allocator state is created lazily from bounded provider-side counts, and legacy rejected records derive their missing slot only when that exceptional reuse path is encountered. Concurrent-start tests cover Firebase, Supabase, and local storage and verify unique indexes.

The PR remains draft until the Firebase before/after timing is recorded.

Checks

• yarn unittest --run — 1,856 passed, 1 skipped
• yarn typecheck
• yarn lint
• yarn build
• Local NASA-TLX fresh-load smoke test — 672, 645, 642, 628, 641 ms; median 642 ms
• Firebase NASA-TLX before/after timing

Closes #1176

[github-actions]

A preview of is uploaded and can be seen here:

✨ https://revisit.dev/study/PR1311 ✨

Changes may take a few minutes to propagate.