#3533 In-memory remote: model create-only data version writes so core tests can pin them (follow-up to swamp-club#3377)

Background

swamp-club#3377 makes the S3 and GCS datastore extensions write data version files create-only (shipping with swamp-club#3508 in swamp-extensions). A data version file is data/<type>/<modelId>/<dataName>/<version>/raw or metadata.yaml. The rules the extensions now apply:

• A new version file is written only if absent (S3 If-None-Match, GCS ifGenerationMatch=0).
• On a precondition failure, the remote bytes are compared. Equal to the local bytes means success (retries, publish-and-verify re-staging from swamp-club#3146).
• Equal to the sha256 this clone last synced for that path (its index entry) means a rewrite this clone owns. Core does this on append() and when it reuses a version number after delete, GC or rollback. The rewrite is a compare-and-swap on what was read.
• Anything else fails with DataVersionConflictError naming the version. Every push then fails the same way until a pull replaces the local version with the remote one.
• The root-to-namespace migration copies version files only onto absent keys, keeps the root original when the namespace key differs, and carries sha256 into the index.

Ask

packages/testing/in_memory_remote.ts uploads by overwrite today (header, lines 20-143). Model the same create-only rule there so core tests can pin the semantics: two clones writing the same new version with different bytes, the loser's error, equal-bytes re-publish, an owning append, and recovery by pull. The ownership check needs the remote to know what the clone last synced, which the fake can take from the clone's index the way the extensions do.

This could not be done in swamp-extensions; it is the core half of swamp-club#3377.