http mode: support static token auth (env) for single-tenant self-hosted deployments

从 pkg/http/middleware/token.go 和 cmd/github-mcp-server/main.go 开始，然后比较 stdio 命令如何读取 GITHUB_PERSONAL_ACCESS_TOKEN 和 GITHUB_ACCESS_TOKEN。当显式选择启用 HTTP 模式后，在 Authorization 缺失时可以使用已配置的环境令牌，同时每个请求的令牌仍优先，并且两者都没有的请求仍保持未授权状态时，即表示完成。

Describe the feature or problem you’d like to solve

github-mcp-server http requires a per-request Authorization header and never reads GITHUB_PERSONAL_ACCESS_TOKEN from the environment - token extraction happens only in pkg/http/middleware/token.go (ExtractUserToken), and httpCmd's ServerConfig has no token field (cmd/github-mcp-server/main.go). The env var is consulted only by the stdio command.

That fits the multi-tenant/centralized use case http mode was built for (#471, #997). But it leaves a gap for single-tenant self-hosted deployments: an org running one server instance with one service credential, fronted by a gateway/tunnel that cannot inject custom headers (in our case, Anthropic's MCP tunnels; the same applies to any transport that forwards requests as-is). The server starts cleanly with the env var set, then 401s every request - a confusing failure, since the README's env-var examples don't mention they're stdio-only.

Proposed solution

In http mode, when no Authorization header is present on a request, fall back to a statically configured token (GITHUB_PERSONAL_ACCESS_TOKEN / GITHUB_ACCESS_TOKEN), opt-in via a flag, e.g.:

github-mcp-server http --static-auth # or --token-from-env

Per-request tokens would still take precedence, preserving the multi-tenant behavior. Notably, the 2026-01-28 GitHub changelog announcing HTTP mode described exactly this fallback ("falls back GITHUB_PERSONAL_ACCESS_TOKEN if no header is provided"), but the shipped behavior doesn't include it.