bazelrc: hold CI remote configs to one connection (TIN-4972)

[Jesssullivan]

Ruling R99 (per Jess, 2026-10-01); ticket TIN-4972.

Failure signature

bazel-remote-gates overflows the GF REAPI cell's blob transfer queue:

RESOURCE_EXHAUSTED: blob transfer pending queue exhausted: pending=64/64

Queue math

The cell admits a fixed number of active ByteStream transfers (2 on the current installation, 8 in the earlier shape) plus a 64-deep pending FIFO, and refuses anything past that. It also caps streams per HTTP/2 connection at active + pending: 66 for 2/64, 72 for 8/64. Bazel's default opens several connections, so the client's in-flight reads and writes can add up to more than the queue holds. With --remote_max_connections=1 the client gets one connection, so it can have at most 66 (and never more than 72) streams in flight. Any extra stream waits at transport admission instead of overflowing the application queue.

This only bounds this client. Independent processes or connections can still fill the queue together, which is why the GF-side companion is xoxd-ai/GloriousFlywheel#2073.

Change

• .bazelrc: build:ci-remote-base --remote_max_connections=1, with a comment giving the reason and the ticket. ci-remote-base is the shared base of ci-cached (the mode remote:check / remote:test / remote:e2e and their :public variants select through scripts/bazel-cache-backed.sh) and of executor-backed. That matches GloriousFlywheel, where executor-backed inherits ci-cached.
• scripts/test-bazel-cache-backed.sh (//:bazel_cache_backed_contract): asserts the line, alongside the existing ci-cached bounds.
• Prior art: GloriousFlywheel .bazelrc line 78, build:ci-cached --remote_max_connections=1, added in 3ae8aa0d (TIN-3701, "bound single-connection blob admission").

Verification

• npm run test:bazel-graph-hygiene: passed.
• bash scripts/test-bazel-cache-backed.sh (fake-bazel contract, no remote): passed.
• No remote builds were run locally. CI on this PR is the real test: bazel-remote-gates has to complete remote:check:public, remote:test:public and remote:e2e:public with no pending=64/64 refusal.

Dependency audit

build-and-test failed at "Static production dependency audit" (npm run security:audit:static) on a new advisory unrelated to the .bazelrc change: dompurify 3.4.13 to 3.4.15, GHSA-p98j-92pf-mc4p (low; IN_PLACE node-removing afterSanitize hook leaves detached subtree event handlers armed). First patched version: 3.4.16.

Second commit, 9966a44, follows the 7fe5b81 precedent:

• package.json: direct dependency dompurify ^3.4.13 -> ^3.4.16. package-lock.json resolves 3.4.16; the transitive mermaid and @zenuml/core uses dedupe onto it.
• pnpm-lock.yaml: regenerated with pnpm 9.15.9 (the rules_js pin in MODULE.bazel), --lockfile-only. It changes only the dompurify entries, plus one registry deprecated: metadata line on eslint@9.39.4 that doesn't change resolution.
• MODULE.bazel.lock: unchanged, because it doesn't record the npm extension.

Local verification (2026-10-01, after npm ci):

• npm run security:audit:static: 0 vulnerabilities for the root and both pulse workspaces.
• npm run lint: clean.
• npm run build: passed. Build side effects under static/ were reverted.
• svelte-kit sync && svelte-check --tsconfig ./tsconfig.json: 0 errors, plus 1 warning that was already there. npm run check fails closed locally by design because BAZEL_REMOTE_CACHE is unset, so bazel-remote-gates is that check's authority.
• npm run test:bazel-graph-hygiene: passed.