fix(memory-sync): only queue failures we attribute to the remote

[LanNguyenSi]

Closes task 1b63070d.

The finding that mattered

The task's AC1 said non-network errors must still crash loud, so launchd
respawns. The code did not guarantee that. performPush's catch had no
classification and no rethrow, so everything raised inside the try block
became "remote unavailable; queued" with exit 0: ENOSPC and EACCES while
writing the working copy, a failing commit, a broken git config,
prepareWorkingCopy and StateStore failures alike.

On a real machine that is the worst possible shape. A full disk logs a benign
queued line every tick, exits 0, is never respawned by KeepAlive, and never
syncs again. Invisible by construction.

The reviewer offered a waiver. I declined it — this runs on both machines
against the real memory remote, and shipping AC1 as met would have been a false
claim about a production safety property.

The fix

RemoteUnavailableError, thrown from lookupRemoteHead and push.
performPush rethrows anything else. Discriminating on exitCode was not
viable: the generic git fallback also throws exitCode 4 for any failing
subcommand, so the code does not carry the information. Message matching was
rejected as revert-sensitive.

Be precise about the boundary, because it is a choice, not a discovery.
prepareWorkingCopy also fetches, and that is equally remote-attributable in
principle. It is deliberately not attributed, because a fetch failure can
just as easily be local (a full disk writing the packfile). So a transient drop
in the window after ls-remote succeeds now crashes rather than queues.
Measured with a stub git: status 0 before, status 4 after.

That is bounded and safe: a sustained outage never reaches the fetch, because
the reachability precheck queues first, and schemes the precheck waves through
are still caught by ls-remote (verified with an unreachable https remote
queueing cleanly at exit 0). It fails loudly and restartably.

Verification

The boundary test uses a stub git binary forwarding everything to real git
except commit, forced to exit 17, raising a non-network failure inside the
try window after the working copy is prepared against a reachable remote.

Confirmed red before the fix — exit 0 with the false "remote unavailable"
note — and the reviewer re-confirmed by stripping the guard from a scratch copy
and getting exactly that failure back.

107 tests, 106 pass. Coverage 94.66 / 75.10 / 93.33 against the 86/65/86 gate.

Also in this PR

• Docs named a class ("a config/data error") that was only true of one
  example. README, machine-setup and the watch plist header now name the
  mechanism.
• restore captures the resolved full sha, so --output json reports the
  commit actually restored from rather than the abbreviation typed.
• resolveLocalCommit no longer advertises branch/tag input it was never safe
  for; the hex precondition enforced elsewhere is now stated at the method.
• A test title that contradicted its body is fixed, the element-shape case it
  hinted at is added, and empty-as-unset is pinned and documented — answering
  the original incident, where an operator tried to disable the probe and there
  was no documented way to do it.

Accepted waiver

AC4's "suite green" is not met and is not restated as satisfied anywhere.
The pre-existing cross-machine-profiles test fails on a hardcoded
/Users/lannguyensi path from a committed profile; confirmed byte-identical on
master and untouched here. Tracked as 112a0864.

After merge

Rebuild and restart the watch and sync launchd services on both machines.
Note this checkout is what the live com.agent-memory-sync.watch.macbook
service runs from, and its dist/ currently holds this branch's build.

Follow-up filed

11424b5e — the mirror image of the fixed bug still exists: a permanently
misconfigured remote is correctly classified and therefore queues silently
forever at exit 0, indistinguishable from a laptop on a plane. Also pins the
deliberate fetch boundary, which no test currently guards.