First sync of a browser-cached drive stalls at hash probe on a fresh server #2116

Connecting a browser-cached workspace to a fresh self-hosted AtomicServer can remain on “Syncing…” indefinitely. The server is online and accepts new drives, but no drive root reaches its store.

Reproduction:

1. Have an existing local/browser drive that the destination server has never stored.
2. Connect the browser to an open self-hosted server and enable “Sync this workspace with this server”.
3. The client sends a hash-first SYNC probe. The engine calls drive_items_for, which requires the root to exist and be readable.
4. The server returns ERROR UNAUTHORIZED_READ: SYNC refused for <drive>: not readable. The client only logs this refusal, leaving sync in progress. Full reconciliation and SYNC_PUSH are never reached.

Expected: for an authenticated session permitted to bring a genuinely new drive to this node, request the full reconciliation with SYNC_RESEND. Keep the existing read gates for stored private drives and admission checks on actual import. A refused drive reconciliation must also terminate the client's progress state with a visible error.

Observed with PR #1870's server at 0f9b5f4 against the hosted browser. The same probe failure path is present in develop at 54eb294. This is separate from the legacy child-first import ordering reported in #2063. The cloud-vault credential warnings seen alongside this are not established as the cause of the localhost refusal.

Regression coverage should include the allowed initial probe/full-import journey, anonymous and policy-denied probes, existing private-drive denial, and client error status versus unrelated subscription refusals.