Store: sync updates for resources without local history trigger 'incomplete Loro import … fetching a full snapshot'

[michielbdejong]

Seen in the atomic-plugins money e2e traces analysed for #1846 (PR #1904). After a reload, the drive sync pushes updates (an app, its agent, its entry point) for resources whose page copy lacks the Loro history those updates were built on. Either they aren't loaded yet, or they were rebuilt from query results (hydrateResourceFromJson) without their oplog. Each logs incomplete Loro import … missing base state, fetching a full snapshot. The store then holds the resource as a still-loading placeholder while it repairs, which delays anything waiting on it (up to getResource's 10 s).

Proposed:

• In Store.applyIncoming (or wherever sync updates are imported), if the resource has no local Loro base, fetch or import the snapshot first, or apply updates that carry a full snapshot directly, instead of attempting a delta import that must fail.
• Make query-hydrated resources record that they have no Loro base, so updates for them go straight to a snapshot.

A test: hydrate a resource from query JSON, deliver a delta update, and it ends up current without a failed import.

[michielbdejong]

Fixed in #1920.

The missing base comes from two things together:

1. The local query doesn't return snapshots. Collection.finishLocalDbPage → hydrateResourceFromJsonAd → hydrateOfflineReplay rebuilds each resource's Loro doc from its values. The result is new ops by a new peer, with no history.
2. addResource wrote that rebuilt doc back to the local database, and putResourceWithSnapshot stores the snapshot as given. So a query read also replaced the stored history. The new lib test shows the write: a snapshot from a single, fresh peer.

The drive sync after a reload diffs against the version vectors from the local database. Its deltas therefore need that stored history, and the rebuilt doc in memory doesn't have it. Each delta became an incomplete Loro import that waited on a full snapshot from the server.

#1920 makes these changes:

• It records which docs were rebuilt without history, and doesn't write them back unless they carry an unsaved edit.
• It replays an unappliable delta on the local database's snapshot first, which is exactly the base the server diffed against. It asks the server only when that fails.

Still open: editing a resource that is without its history saves from the rebuilt doc, as before. Loading the local snapshot before the first edit would close that.