tracking(mcp): complete the post-V3 roadmap

## Problem

The dual-era MCP V3 rollout is complete in #1650, but the architecture document
still lists post-V3 work without one current coordination tracker. Some slices
have since shipped or gained their own tracker, while the remaining ownership
is fragmented.

## Desired outcome

Maintain one authoritative view of MCP work after V3. Each implementation slice
may use its own focused issue and PR; this tracker closes when every item is
either shipped or linked to a durable child tracker and the architecture
document reflects its current state.

## Checklist

- [x] Ship OAuth discovery, PKCE, dynamic client registration, Desktop login, and secret-safe IPC (#2919, #2920)
- [ ] Move MCP tokens and remaining credential-bearing configuration to platform-backed secret storage
- [ ] Add resources/templates browse, read, subscribe/unsubscribe, and host UI
- [ ] Add an authenticated loopback MCP proxy for controlled subprocess clients
- [ ] Give config reload, per-server health, bounded backoff, and crash recovery one lifecycle owner; coordinate with #3838
- [ ] Define finer-grained MCP permission policy without trusting server annotations
- [ ] Add signed remote catalogs, last-known-good caching, guided setup schema, package provenance, and update permission diffs
- [ ] Keep the architecture document synchronized as child work lands

## Non-goals

- Reopening the completed protocol rollout in #1650
- Duplicating TUI MCP management or remote publication from #3838/#4200
- Delivering the roadmap as one large PR
- Moving Client-owned MCP transports or child-process ownership into Runtime Host
- Adding MCP Apps, Tasks, or `input_required` handling here

## Documentation

- [MCP runtime architecture](https://github.com/apache/maka/blob/main/docs/architecture/mcp-runtime-architecture-draft.zh-CN.md)

Start by reading docs/architecture/mcp-runtime-architecture-draft.zh-CN.md and reviewing the referenced trackers #1650, #3838, and #4200. Map each unchecked roadmap slice to either shipped work or a durable child issue, then update the architecture document as work lands. Done means every checklist item is shipped or linked and the document reflects the current state.

Written by the indexing model from the issue text.