A vault file whose `gitmost_id` is a WELL-FORMED UUID that matches no page (a stale
id from a restored-from-backup file, or a copied/foreign id) fell through
importPageMarkdown to writeBody() on a non-existent page, throwing "Page … not
found". The push apply recorded that as a per-cycle failure that never cleared —
refs never advance, so the whole space's sync looped on the failure indefinitely
(observed live: a leftover orphan file kept a space stuck at "1 failure" every ~5s).
Same user-visible impact as C9-D1, but the id is a valid uuid so the 22P02 guard
does not catch it.
Add the missing `currentPage == null` branch in importPageMarkdown: skip the
unknown id as an inert no-op so the cycle succeeds and the rest of the space keeps
syncing. Verified on the stand: pushing a valid-but-nonexistent gitmost_id now stays
at 0 failures (was 1/cycle forever), logs a skip warn, and a concurrent legit edit
still syncs. Unit test added; server suite green (2146).
NOTE (separate design follow-up, not this commit): the reconcile still cleans the
orphan file (it maps to no live page). ADOPTING such a file as a fresh page (the
restore-from-backup use case, preserving the git-authored content) needs the title
from the filename, which lives in the engine classifier, not this method.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
agent_qa
e6a861bdaf