Support declaring a token's granted permissions/scopes up front for tool pre-filtering (stdio config + HTTP header)

Beginne mit CreateToolPermissionFilter aus #2676 und der bestehenden pkg/scopes-Filterung; verfolge dann den stdio-OAuth-Pfad und die HTTP-Anfrageverarbeitung. Als abgeschlossen gilt, wenn eine dokumentierte Grant-Deklaration beide Filter im stdio-Modus und im HTTP-Modus pro Anfrage speisen kann, während fehlende Deklarationen das Fail-open-Verhalten bewahren und die Laufzeitautorisierung unverändert bleibt.

Problem

We filter tools by what a token can do in only a few narrow cases today:

• Classic PATs (ghp_) — we read the X-OAuth-Scopes response header and hide tools requiring scopes the token lacks.
• OAuth login (stdio) — we filter by the requested OAuth scopes (default set hides nothing; a narrower --oauth-scopes filters).

For everything else we fail open and show every tool:

• Fine-grained PATs and GitHub App installation tokens do not advertise their granted permissions in a way we can read up front.
• The FGP requirement subsystem from #2676 ships dormant in OSS precisely because there is no grant source — CreateToolPermissionFilter(granted) fails open on a nil granted.

The result: a token that physically cannot perform an action still surfaces the tool, so the model discovers the limitation only by calling it and getting a 403. We already know the catalog of what each tool needs (#2676/#2679); what's missing is a way to tell the server what the token actually has.

Proposal

Let the operator declare the token's granted permissions/scopes up front, independent of OAuth, so we can pre-filter tools against the FGP catalog (#2676) and the classic scope catalog (pkg/scopes):

• stdio: a config flag / env var, e.g. --granted-permissions / GITHUB_GRANTED_PERMISSIONS (fine-grained) and/or --granted-scopes / GITHUB_GRANTED_SCOPES (classic). Applies regardless of whether the token came from a PAT, a GitHub App installation token, or OAuth.
• HTTP mode: a request header (e.g. X-MCP-Granted-Permissions) carrying the same declaration per request, so a remote host that already knows the caller's grant can drive filtering without us re-deriving it.

When a grant declaration is present, feed it as the granted source to CreateToolPermissionFilter (FGP) and to the existing scope filter, so tools the token cannot use are hidden. When absent, keep today's fail-open behavior.

Caveats (call out in the design)

This is deliberately flagged as a sharp-edged feature:

• Manual and messy interface. Enumerating fine-grained permissions + levels (read/write/admin) by hand is verbose and error-prone. The format needs thought — a flat perm:level list is ugly; anything richer is heavy for a CLI flag / header.
• No validation against the real token. A declared grant can drift from what the token actually has. Over-declaring hides nothing it shouldn't but re-introduces the 403-on-call surprise; under-declaring hides usable tools. We are trusting the operator's declaration.
• Two vocabularies. Classic scopes vs fine-grained permissions are different models; we'd need to be explicit about which a given token uses (and possibly support both).
• It is a pre-filter for ergonomics/safety, not an authorization boundary — GitHub still enforces the real permissions server-side.

Context / related

• #2676 — declarative FGP requirement subsystem (catalog + CreateToolPermissionFilter, ships dormant; this issue is the grant-source piece that's out of scope there).
• #2679 — expand per-tool FGP annotations.
• Existing classic-scope filtering for ghp_ PATs and OAuth requested scopes (stdio).
• OAuth stdio stack (in progress) — OAuth can only filter by requested scopes, and even then we don't know the granted set from the app alone; this issue is the general, OAuth-independent mechanism.

Out of scope

• Auto-deriving grants from the token (not generally possible for fine-grained PATs / installation tokens).
• Any change to runtime per-call authorization — GitHub remains the enforcement point.