RFC: Graceful Degradation for Multi-Upstream OAuth in vMCP (#72)

Adds an RFC proposing opt-in partial-completion semantics for the
embedded authorization server's multi-upstream OAuth chain in
VirtualMCPServer.

## Why

Today the embedded auth server's multi-upstream chain is all-or-nothing:
one upstream IdP outage or one declined consent screen invalidates every
collected token and locks the user out of every backend on the vMCP —
including backends that have nothing to do with the failed upstream.
Operators aggregating backends across multiple SaaS IdPs (e.g. github +
slack + google) see the whole vMCP appear down for what should be a
single-provider problem.

## Key design decisions

- New `partialUpstreamAuth` mode on `EmbeddedAuthServerConfig`
  (`requireAll` default | `allow`) and a per-upstream `required` flag
  (default `false`, honored under `allow`).
- Primary identity provider — already named by
  `authzConfig.inline.primaryUpstreamProvider` — is always required;
  admission webhook rejects configs that mark it optional.
- Chain walks every upstream and completes when every required upstream
  has a token; optional upstreams that error or are declined are
  recorded as session-scoped skipped tombstones.
- Recovery is restart-all only: the client's normal `/authorize`
  re-entry wipes prior session tokens and walks the chain again.
  Per-upstream retry is explicitly rejected — identity-binding hazards
  outweigh the round-trip savings.
- Backends whose required upstream is missing are filtered out of
  `tools/list`, `resources/list`, etc., and refused at dispatch.
- vMCP does not extend the MCP protocol to signal filtered state.
- Refresh-token expiry and out-of-band revocation are detected
  reactively (no introspection poller) and recover via the same
  restart-all path.

## Out of scope

Per-upstream retry, MCP-protocol-level signaling of filtered state,
silent backend dropping on RT expiry, proactive token introspection,
dynamic upstream addition.

Author: tgrunnagle