bazel l1 [fork 3/5]: client-side forwarding + marker-based degradation

[shreyas-blacksmith]

Piece 3 of 5 peeled off shreyas/bazel-l1-goal-state (design record: FastActions/fa#4779). Base: piece 2 (#28). One commit (840d6fb).

Summary

• The client half of the trust + routing contracts, in grpcproxy (what the embedded FA host runs): forwards the tenant's storage prefix, auth secret, and pinned S3 (endpoint, bucket) selector as outgoing gRPC metadata on the synchronous path, and captures them per queued item so asynchronous write-throughs carry the same identity after the request context is gone.
• Typed rejection handling: an L1 response carrying the cache.blacksmith.sh ErrorInfo marker (piece 2's STORAGE_PREFIX_REJECTED / piece 4's S3_BACKEND_SELECTOR_REJECTED) degrades to a metered local miss — never a build failure; unmarked errors keep their existing semantics.

Dark until an FA host is configured with L1 mode + the secret; merging is harmless.

Evidence

Staging E2E 2026-07-29→30: negative-trust and unknown-selector runs degraded client-side to metered misses (exit 0) while the node counted and journaled the rejections.

Made with Cursor

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled. (Staging)}

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[piob-io]

The idempotency guard in withOutgoingStoragePrefix/withOutgoingS3Backend checks key presence in the outgoing metadata, not equality — if an outer layer ever attached a different prefix or endpoint, the inner call would silently defer to it rather than flag the conflict. Today the only re-entry is Contains(RAW/AC) delegating to Get on the identical context, so this can't fire, but the presence check encodes "someone already set this, trust them" where the intent is "don't attach twice". Worth either asserting equality (log + prefer the request-scoped value) or a comment noting the assumption that all layering paths share one context.

[piob-io]

isTransportFailure counts codes.Canceled into transport_miss_total, but a Canceled here is usually the caller's context dying (Bazel gave up, request torn down) — not L1 trouble. Mixing it in means the transport-miss series inflates with client-induced cancellations, which muddies any "L1 unhealthy" alert on it. Two options: distinguish caller-cancel from backend failure by checking ctx.Err() == context.Canceled before classifying, and either skip the meter entirely (degrading to a miss is still right, the caller is gone anyway) or count it under a separate label/reason (e.g. transport_miss_total{reason="client_canceled"}), leaving the alertable series clean.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 3 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1a46c90. Configure here.}

[shreyas-blacksmith]

@piob-io thanks for the review

• idempotency guard: agreed, now idempotent by value. Same value no-ops, a conflict is logged and the request-scoped value wins.
• Canceled: caller-dead cancellations still degrade to misses but meter on a separate client_canceled_miss_total, so transport_miss_total stays a clean L1-health signal.

[piob-io]

FA's forwarded-CAS→created metrics mapping keys on successful forwards carrying an empty reason (if key.Reason == "" before tagging l1_forwarded). Both forwarded emit sites here do pass "", but nothing pins that: TestObserveUploadCarriesEntryKind asserts Method/Kind/Status/Bytes and never Reason. Adding if outcome.Reason != "" { t.Errorf(...) } to that test — with a comment naming the fa consumer (build_cache_metrics.go's forwarded→created mapping) — turns the cross-repo assumption into a tripwire on the side that can actually break it.