Public per-session initial-load signal on collections (adapter read gates)

Outcome

A public, per-session "initial load complete" signal on the collection: a boolean plus a subscription, reset when a sync session starts, set when the session's first sync commit lands. Sync adapters could then delete the equivalent flag they each maintain, and useLiveQuery consumers could tell "ready because this session loaded data" apart from "ready because of a seed or a revival".

Why the existing signals do not cover it

Our adapter falls back to a cached snapshot until the collection has loaded in the current sync session. The public signals answer a different question:

• collection.isReady() and status: 'ready' describe the collection's lifetime. They stay true after a GC-and-revive cycle, although the revived instance's data was cleared. They also stay true when a load fails after an earlier success. A read gate built on them serves an empty or stale collection instead of the healthy fallback.
• hasBeenReady is per-session but private (collection._lifecycle) and has the same revival behavior.

What we do today

We keep a boolean in the collection-options scope: set on snapshot commit, reset on every sync start, exposed through collection.utils with a subscribe. It works, but it duplicates state the library already tracks.

Start with the collection-options scope and the collection's private _lifecycle state, then trace the existing snapshot-commit and sync-start paths. Done means the collection exposes a public per-session boolean and subscription, resets them at sync start, sets them after the first sync commit, and lets adapters remove their duplicate flag.