Hydration seeds should be able to carry adapter syncMeta (seed revision)

Outcome

Let a hydration seed carry an adapter-defined syncMeta value, delivered to the sync closure the way importSyncMeta already delivers collection metadata. An adapter could then record "these seeded rows are valid as of version N" with the rows, and decide skip-or-fetch from one source.

Behavior

With DbClient.hydrate, a loader seeds a live query's rows so the server render and the hydration render paint data before sync starts. Our seeded rows come from a versioned snapshot read. On the client, the sync closure must decide whether that version already covers the current connection (skip the initial fetch) or a fresh snapshot is needed.

The seed carries rows but no adapter metadata, so the version cannot travel with them. Our sync closure reads it from a second cache where the loader also stored the snapshot. Two caches now answer one question, and they can disagree.

importSyncMeta already runs before the sync closure, so the delivery path exists. There is no public way for a loader-side seed to supply the value.

Start at the DbClient.hydrate loader path and trace how seeded rows reach the live query and how importSyncMeta reaches the sync closure. Identify the existing adapter metadata delivery and hydration seed flow before deciding where the seed's syncMeta belongs. Done means the sync closure can use the seed revision before its initial fetch, without relying on a second cache.