Add HTTP (streamable) MCP server + Tower gateway support

[galligan]

Goal

Enable Firewatch MCP to run over streamable HTTP (SSE) so remote agents can connect via a Tower gateway, while keeping stdio as the default local mode.

Proposed design

• Add HTTP transport mode to apps/mcp (e.g. fw-mcp --http or FW_MCP_TRANSPORT=http).
• Use the MCP SDK’s streamable HTTP transport (POST/GET/DELETE on /mcp with SSE).
• Keep the same tool contract (firewatch tool with action dispatch).
• Server owns cache + auth; clients only send params (e.g. repo).

CLI / packaging

• Publish/ship fw-mcp with an HTTP entrypoint.
• Example: npx @outfitter/firewatch-mcp --http --port 8787
• Stdio remains the default for local use.

Tower gateway integration

• Tower terminates TLS + auth; forwards to Firewatch MCP.
• Preserve mcp-session-id + mcp-protocol-version headers.
• Optional gateway auth -> principal injected into MCP env or headers.

Remote agent UX

• .mcp.json uses the Tower URL.
• Requests should include explicit repo (avoid needing a local cwd).
• Optional projectRoot / principal for per-user routing.

Security + tenancy

• GitHub tokens stored server-side (env/Vault); no client tokens required.
• Namespace cache paths by user/team (principal from gateway).
• Rate limiting and repo allowlist on the server/gateway.

MVP tasks

• Add HTTP transport entrypoint in apps/mcp (Hono or fetch).
• Wire MCP SDK streamable HTTP transport.
• Ensure action tool works identically to stdio.
• Add config for PORT, FW_MCP_TRANSPORT, and optional FW_MCP_PRINCIPAL.
• Add docs section for Tower gateway + .mcp.json example.
• Add smoke test / curl script for /mcp handshake.

Open questions

• How should we map gateway identity to cache/config isolation?
• Do we want a server-side repo allowlist?
• Should HTTP mode auto-disable local git checks (file-level staleness) unless repo path is provided?
• Any Tower-specific headers/constraints we should bake in?