Fixes #13317.

Summary

gh api and gh api graphql were silently sending requests without an Authorization header when gh's keyring lookup failed — typically when the 3-second timeout in internal/keyring/keyring.go fired against a macOS Keychain entry whose ACL had drifted (e.g. an entry written by an older gh that now requires an interactive approval the non-TTY child process can't surface). Users saw only HTTP 401 (REST) or HTTP 403 "API rate limit exceeded for <IP>" (GraphQL) with no signal that the local keyring was the cause.

The bug was a silent error discard at two layers:

1. (*config.AuthConfig).ActiveToken swallowed keyring errors from TokenFromKeyringForUser / TokenFromKeyring and returned ("", source).
2. AddAuthTokenHeader.RoundTrip then saw an empty token and proceeded with no header — indistinguishable from a legitimate anonymous request.

What changed

• Added ActiveTokenWithError(hostname) (token, source, err) to gh.AuthConfig and *config.AuthConfig that surfaces non-ErrNotFound keyring errors.
• Refactored (*AuthConfig).ActiveToken as a thin wrapper that calls ActiveTokenWithError and discards the error, preserving its existing signature for every current caller.
• Required ActiveTokenWithError on api/http_client.go's local tokenGetter interface; updated the cfg adapter in internal/authflow/flow.go and the tinyConfig test mock to match.
• AddAuthTokenHeader.RoundTrip now calls ActiveTokenWithError. On non-nil error it fails the request with that error; on nil error + empty token it proceeds anonymously (preserves anonymous-endpoint behavior); on nil error + non-empty token it attaches the Authorization header as before.
• keyring.ErrNotFound continues to be the legitimate "no token configured for this host" signal and is not surfaced as an error, so anonymous requests against unconfigured hosts keep working unchanged.

What stays the same

• The gh.AuthConfig.ActiveToken signature and behavior for every existing caller.
• Test mocks that don't directly satisfy tokenGetter (e.g. stubAuthConfig in pkg/cmd/attestation/trustedroot/trustedroot_test.go) — stubAuthConfig embeds config.AuthConfig so it inherits the new method automatically.
• Anonymous-endpoint behavior (gh api zen against a host with no configured user still proceeds without an Authorization header).

Alternatives considered

Follow-ups (not in this PR)

Other call sites of ActiveToken would benefit from migrating to ActiveTokenWithError so the same class of silent failure can't recur in those code paths. Left for a follow-up to keep this PR focused:

• pkg/cmd/auth/status/status.go:238 — gh auth status can mis-report keyring failures as "no token"
• pkg/cmd/auth/refresh/refresh.go:178,229
• pkg/cmd/auth/token/token.go:81
• pkg/cmd/auth/shared/writeable.go:10
• pkg/cmd/config/get/get.go:58

Adding // Deprecated: to ActiveToken is also deferred to that follow-up — adding it now would generate SA1019 warnings on every existing call site without giving users a migration path.

Test plan

• go vet ./... clean.
• go test ./... -short passes (full suite).
• New tests in internal/config/auth_config_test.go:
  • TestActiveTokenWithErrorSurfacesKeyringFailure — keyring error is wrapped and returned.
  • TestActiveTokenSilentlyDiscardsKeyringFailure — ActiveToken (the wrapper) preserves its no-error contract.
  • TestActiveTokenWithErrorDoesNotSurfaceErrNotFound — ErrNotFound returns (token="", err=nil).
  • TestActiveTokenWithErrorReturnsEnvTokenWithoutKeyring — env-var path short-circuits keyring entirely.
  • TestActiveTokenWithErrorReturnsKeyringToken — successful keyring resolution returns (token, "keyring", nil).
• New table-driven TestAddAuthTokenHeaderResolutionPaths in api/http_client_test.go covering: error fails the request, resolved token is attached, empty token without error proceeds anonymously.
• Manually verified the patched binary built from this branch continues to authenticate correctly against a healthy macOS Keychain (gh api user returns HTTP/2 200, x-ratelimit-limit: 5000, resource: core; same for GraphQL).