feat(credentials): load every owner's PAT at launch, failing closed per token

[twistedmelonman]

Why

A fine-grained PAT is bound to one resource owner at creation, so no single token covers the fleet. Reading an org's repos with the personal token fails 403 on branch protection and 404 on the repo itself — whether that repo is public or private, because the boundary is ownership, not visibility.

Selecting one token per session from the launch directory therefore guarantees the wrong credential for any cross-owner work, which fleet probes and rollouts are by definition. The documented workaround was env -u GH_TOKEN, which falls back to the keyring OAuth token and defeats the per-owner routing the gh wrapper enforces.

What

Load all three PATs at launch as GH_TOKEN_SWM / GH_TOKEN_NOS / GH_TOKEN_TWM.

Additive. GH_TOKEN keeps its launch-directory selection, so nothing that reads it changes. This is option 1 from the token-architecture decision; option 3 (gh-wrapper routes per invocation) is the eventual target and is what #126 tracks.

Fetched once at launch rather than per use: a 42-repo probe would otherwise mean dozens of vault reads, making the correct path slower than the fallback it replaces — which is how workarounds get entrenched.

Also extracts _creds_read_token_ref() from _load_gh_token(). The retry/backoff/timeout handling was already correct and is now shared rather than duplicated. It prints to stdout, returns 1 on failure, and never exports or logs a value. _load_gh_token's behavior is unchanged.

Failing closed

Each token fails closed independently. A failed fetch exports the invalid sentinel, never an empty string — an empty value would let gh fall through to the user's keyring OAuth token (repo/workflow/admin:org), silently widening the agent's access on a transient vault failure. A partial failure poisons only its own variable.

Verification

This is the part that was previously blocked. The fail-closed path is the test that leaked tokens in an earlier session, so it was left unverified.

It is now covered safely: every assertion compares against the fixed sentinel literal or a stub-supplied value. The stub op never returns a real credential. A test that must echo a live token to prove itself is the test that leaks it.

8 new cases in test-credentials.sh (32/32), with a known-bad gate first:

Case	Asserts
No OP_SERVICE_ACCOUNT_TOKEN	nothing exported, op never called (known-bad gate)
All refs resolve	each var loaded from its own ref
All refs fail	every var gets the sentinel
One ref fails	only that var gets the sentinel
Failure warns	degraded session is visible
Already set	preserved, and its ref never read

Verified by mutation, not just by passing — a green suite over broken code has burned this repo before:

Mutation	Result
Fail open (empty instead of sentinel)	2 failures
Drop the already-set guard	3 failures
Point every var at one ref	3 failures

Full suite 133/133 across test-credentials, test-launch-dir-check, test-remote-session, test-wrapper. shellcheck -S info clean.

Pre-existing failure, not from this change

test-gh-token-permissions.sh reports Token authentication failed (got: 'twistedmelonman'). It reproduces identically on a clean tree (verified by stashing).

That failure is #126: GH_TOKEN resolves from the launch directory, so a session started in a smartwatermelon repo still authenticates as twistedmelonman. This PR supplies the per-owner tokens that fix will select among; it deliberately does not change GH_TOKEN selection.

Advances #126

https://claude.ai/code/session_017s2qrmkQaV54fbcMzB2KRm