feat(gateway): expose charter_brief through stackbilt-mcp-gateway with per-tenant repo targeting

[stackbilt-admin]

Context

Post-v0.1 follow-up to #113 (charter_brief MCP tool in charter serve).

charter serve is per-repo — one MCP server instance per Charter-governed repo. Multi-repo agent workflows (which is the direction autonomous agents are heading, driven by cc-taskrunner and aegis-daemon spawns across 10+ repos) need brief access without spinning up one charter serve per repo.

The stackbilt-mcp-gateway is ecosystem-wide and already brokers OAuth + tool access across Stackbilt properties. Natural home for a gateway-hosted brief-fetcher.

Open questions

1. Invocation shape: charter_brief today takes no arguments — it's "this repo, now." Through the gateway, agents need to specify which repo. Options:
   • New tool name (e.g. stackbilt_repo_brief) with a repo: string argument — decouples from the per-repo tool entirely
   • Same charter_brief name, gateway injects the repo from tenant/session context — transparent to the agent but implicit routing
2. Brief freshness: gateway serves a central cache vs. proxies to the per-repo charter serve instance. Cache has a consistency problem (when does it invalidate?); proxy has a cold-start cost.
3. Auth scoping: which tenants can read which repos? Read the existing gateway OAuth model and reuse — this shouldn't invent new permissions.

Not v0.1

charter_brief ships through per-repo charter serve first (#113). Gateway exposure is a separate ecosystem integration that lands once the brief format is stable and we have real multi-repo agent workloads asking for it.

Related

• feat(adf): auto-populate context modules from blast/surface/classify — reduce LM-agent cold-boot token cost #113 — charter_brief source feature
• stackbilt-mcp-gateway — receiving system
• cc-taskrunner — primary consumer of multi-repo agent workflows
• aegis-daemon — secondary consumer (hourly autonomous cycles across portfolio)