feat(http): add opt-in static authentication

[dawNotPoi]

Summary

Add explicit opt-in static authentication for single-tenant HTTP deployments.
When enabled, requests without an Authorization header use the process
GITHUB_PERSONAL_ACCESS_TOKEN; per-request credentials remain authoritative.

Why

HTTP mode currently requires every caller to supply an Authorization header,
even when a single-tenant deployment already has a service credential in the
process environment. Gateways and tunnels that cannot inject custom headers
therefore receive a 401 for every request.

Fixes #2946

What changed

• Add the HTTP-only --static-auth flag and GITHUB_STATIC_AUTH environment
  equivalent, with startup validation for the configured token.
• Fall back only when the Authorization header is absent; explicit empty,
  malformed, or unsupported headers remain errors.
• Preserve existing token-context and PAT-scope processing, and document the
  shared-credential security boundary.
• Reject browser-origin requests that would implicitly consume the shared
  credential, while preserving explicit bearer-token CORS and OAuth metadata.

MCP impact

• No tool or API changes
• Tool schema or behavior changed
• New tool added

HTTP transport authentication behavior changes only when static auth is
explicitly enabled. MCP tool definitions and schemas are unchanged.

Prompts tested (tool changes only)

• N/A — this changes HTTP authentication configuration, not an MCP tool.

Security / limits

• No security or limits impact
• Auth / permissions considered
• Data exposure, filtering, or token/size limits considered

Static authentication is disabled by default. When enabled, every caller that
omits the header receives the shared credential's permissions, so the docs
require an authenticating trusted gateway or access boundary and recommend
least privilege and --read-only; loopback alone is not presented as
authentication. Browser-origin requests cannot consume the fallback token.
Explicit request credentials always take precedence, and configuration errors
never include the token value.

Tool renaming

• I am renaming tools as part of this PR (e.g. a part of a consolidation effort)
  • I have added the new tool aliases in deprecated_tool_aliases.go
• I am not renaming tools as part of this PR

No tools are renamed.

Lint & tests

• Linted locally with ./script/lint
• Tested locally with ./script/test

./script/lint reports zero issues. ./script/test and an uncached focused
go test -race -count=1 ./pkg/utils ./pkg/http/... ./cmd/github-mcp-server
both pass.

Docs

• Not needed
• Updated (README / docs / examples)

Updated docs/streamable-http.md with configuration, precedence, startup
validation, browser-origin behavior, and shared-credential safety guidance.

[tiagovilasboas]

Staff AppSec (HTTP static-auth)

Verdict: Approve with comments (conversation comment — formal review UI often disabled here.)

Opt-in --static-auth / GITHUB_STATIC_AUTH for single-tenant HTTP is implemented carefully: default-off, fail-closed token validation (secrets not echoed), fallback only when Authorization is absent (empty/malformed never downgrade to the shared PAT), StaticAuthBrowserGuard before CORS so Origin requests cannot consume the ambient credential, and PAT-scope middleware still sees the fallback token. Docs WARNING correctly says loopback ≠ auth.

Residual (acknowledge on merge): this authenticates callers to the MCP server with nothing — any non-browser client that can reach the socket and omits Authorization gets the shared PAT. The Origin guard is browser/ambient protection only.

Non-blocking asks: (1) loud startup warning when static auth is on and listen host is not loopback; (2) startup warning when static auth is on without --read-only (docs recommend it; writes under a shared PAT are the scary case). Happy to re-check if those land as a follow-up.

Refs #2946.