#4033 Refused-push restore (discardRefusedVersions) writes markers and content unsynced and out of order

Description

Split out of swamp-club#4017 (durable v2 data-version writes).

After a refused push (lock lost on a v2 custom datastore, swamp-club#3485), discardRefusedVersions in src/cli/repo_context.ts deletes the refused versions through the repository. It then restores the removed files and the latest markers from the datastore with fetchContent and atomicWriteFile. Those restores are not synced, and the markers can be restored before the content they name:

• atomicWriteFile writes temp+rename with no fsync. A power cut can keep a restored latest marker while the restored raw or metadata.yaml it names comes back empty: the swamp-club#3955 end state.
• The removed-path set interleaves content and markers: one version's files, then its name's latest, then a later version's files. So a marker can be restored, and become durable, before a later version's content.
• ensureDir creates version directories whose entries in the data-name directory are not synced before a marker names them.
• A fetched marker can name a version this restore never fetched, for example one the new lock holder pushed. It is restored anyway. A lazy pull downloads metadata.yaml and latest markers and hydration fetches only raw, so a version with no local metadata.yaml is not normal state under lazy hydration either.

Expected

• Restores use #4017's atomic write sync option (full sync).
• Every content file is restored first. Then every directory from each restored version directory up to the cache's data root is synced, once each. Then the markers are restored.
• A fetched latest marker whose version has no local metadata.yaml is not restored, with or without a hydrate hook.
• integration/model_lock_lost_push_test.ts covers the order and the skip.

Builds on #4017's sync option. It touches only the cli restore path, so it can land independently once that option exists.