fix: the session bearer on a plain-http read accelerator breaks every browser block read

[FSM1]

Since #1243 the engine stamps the member's session JWT onto every read-accelerator request, and crates/engine/src/content/read.rs treats a loopback accelerator as able to keep it:

matches!(host, "localhost" | "127.0.0.1" | "[::1]")

No browser can deliver that header to such a gateway. Authorization makes the cross-origin block read non-simple, and a stock Kubo gateway answers the preflight with

Access-Control-Allow-Headers: Content-Type, Range, User-Agent, X-Requested-With

which omits it. Measured in the page against the local stack:

request	result
Accept: application/vnd.ipld.raw	200, 1052 bytes
the same plus Authorization: Bearer …	Failed to fetch — preflight rejected

What it breaks

VITE_PUBLIC_GATEWAYS is unset in apps/web/.env, so the accelerator is the only content source and there is nothing to rotate to. Every block read fails, so:

• the root never adopts, and the resolve tick reports RefreshVerdict::Unreachable — the chrome shows refresh failed: no endpoint served a record this pass could adopt
• Drain::load_scope_root (crates/engine/src/sync/drain.rs:838-852) cannot assemble the head envelope and returns Halt::UploadAttempt, so a queued write never publishes

The write stays pending with no dead letter, and the status indicator still reads synced. A cold start to an empty vault still works, which is why the smoke tier never saw it.

Reproduction

Against the local stack with VITE_READ_ACCELERATOR_URL=http://127.0.0.1:8080: log in, create a folder, force one refresh pass, wait. The child stays pending: "metadata" forever. Allowing Authorization in that Kubo's Gateway.HTTPHeaders makes the same build pass 11 of 11 web e2e specs.

Why no test caught it

crates/engine/tests/write_plane.rs builds engines on ApiBaseUrl::offline() and plants records, so "first-run mint then a queued write drains" is never composed. The gateway tests drive a scripted HTTP fake and assert only that the header is present. CORS exists only in a browser, so the web e2e write path is the first suite in the repo that can catch this class.

Fix

TLS is the whole rule: a plain-http accelerator falls to GatewaySource::public and still serves reads, unauthenticated. That also stops the session token reaching a gateway the host does not own.

Related, not covered here

Whatever accelerator staging points at must list Authorization in its CORS allow-list, or the deployed web app fails the same way.

[FSM1]

The fix lands in #1246 (carries_credentials_safely admits TLS and nothing else, and GatewaySource::accelerator is now the only way a leg receives the bearer). Three things the security and crypto reviews of that diff surfaced are not fixed there and want their own decision:

1. The failure is undiagnosable, which is why this cost a day. Every non-2xx — 401 and 403 included — hits the bare continue in crates/engine/src/content/read.rs:320-322, and the exhausted source set surfaces as ReadError::Unavailable. crates/engine/src/sync/drain.rs:853 then maps any head-assembly error to Halt::UploadAttempt: a charged retry with no operator-visible reason. The member sees a write that stays pending, no dead letter, and a status indicator reading synced. The trust verdict is right — a 401 is not an integrity signal — but nothing distinguishes "the gateway refuses me" from "the block is not there yet".

2. Denying the token is silent, and it can widen the CID audience. into_gateway emits no event when it withholds the bearer. If a deployment's accelerator requires auth, every read now 401s and rotates to public_fallbacks — handing the member's read CID set to a third-party gateway that never saw it before, with no event. The shipped local config leaves VITE_PUBLIC_GATEWAYS empty, so nothing rotates today; a real deployment is a different matter. Surfacing the denial once at construction would cover both this and item 1.

3. A second, weaker credential policy exists. The load harness sends LOAD_TEST_GATEWAY_TOKEN to any scheme, http://localhost:8080 included — crates/load/src/runner.rs:87-98, default at crates/load/src/plan.rs:122. It never consults carries_credentials_safely. Pre-existing and outside the fix.

Also worth pinning before anyone points the accelerator at a deployed gateway: the CORS half of this is scheme-independent. A stock Kubo over TLS rejects the Authorization preflight exactly as the loopback one did, so the deployed gateway must list that header explicitly. Today no accelerator is configured anywhere — vars.VITE_READ_ACCELERATOR_URL exists at neither repo nor staging scope, and the staging Kubo gateway is bound loopback-only with no vhost — so nothing is broken in a deployment right now.