Fleet: prevent low-scope GitHub tokens from shadowing keyring credentials

[willwashburn]

Problem

A Relay-spawned session can inherit GITHUB_TOKEN or GH_TOKEN from the
launcher. GitHub CLI gives those environment variables precedence over its
keyring credential.

When the inherited token is scoped only for public_repo, private-repository
operations fail with repository not found. That message looks like an absent
repository rather than an authentication-source mismatch and caused a false
conclusion during the 2026-07-30 fleet session.

Current workaround

Run the GitHub command without the injected environment-token overrides:

env -u GITHUB_TOKEN -u GH_TOKEN /opt/homebrew/bin/gh <cmd>

Do not use gh auth status as a routine diagnostic: it inspects credential
state when the operation can instead remove the known override.

Expected behavior

Spawned sessions must not silently replace the operator's keyring-backed GitHub
identity with a lower-scope inherited token.

Acceptance criteria

• Define explicit inheritance policy for GITHUB_TOKEN and GH_TOKEN on
  spawned sessions.
• Strip launcher-provided GitHub tokens by default, or require an explicit
  opt-in when a task intentionally needs that token.
• Ensure private-repository access uses the expected keyring credential when no
  explicit token handoff was requested.
• When an explicit token is insufficient, report an authentication-source or
  scope problem rather than presenting repository not found as authoritative.
• Add regressions for a public-only environment token plus a keyring credential
  that can read a private repository.
• Never print token values in errors, logs, or diagnostics.