A transient transport error during reconciliation leaves the daemon blocked_corrupt until it is restarted #111

Follow-up to #106. With the fix from #107 the daemon survives a laptop sleep and reconciles again on wake. On the first real sleep since, that reconciliation hit the network before it was back, and the daemon ended in a terminal state:

2026-10-05T23:37:42Z  ready_current              (last refresh before sleep)
2026-10-05T23:40:16Z  reconciling                (record expired; re-reconciling on wake)
2026-10-05T23:45:36Z  blocked_corrupt  git ls-remote origin failed: fatal: unable to access
                      'https://github.com/magnificentlycursed/crosslink.git/': Recv failure: Connection reset by peer

blocked_corrupt is terminal and sticky: the daemon stayed alive in it for 19 hours, daemon ensure --wait-ready returned the blocked record, and every command and hook stayed blocked until daemon stop plus ensure.

Cause: is_remote_unavailable_message (reconcile/publication.rs) recognises "could not resolve host", "could not read from remote repository", "connection timed out", "connection refused", "network is unreachable", "no such file or directory" and "does not appear to be a git repository". Anything else from the remote, including "Connection reset by peer", "Recv failure", "Could not connect", "SSL", "early EOF" and the generic curl "unable to access", is Rejected, which activation maps to blocked_corrupt.

Ask:

1. Treat transport failures as Unavailable (the waiting_for_remote path, which already retries with backoff). A safe rule: any fatal: unable to access from git is transport, and "connection reset by peer", "recv failure", "could not connect", "failed to connect", "ssl" and "early eof" are transport.
2. Consider not letting a remote failure during re-reconciliation (as opposed to a verification failure) be terminal at all, since the daemon reached ready_current with the same hub minutes earlier.

Authored by Claude Code on behalf of @magnificentlycursed.