Existing sessions hold a stale MCP tool surface: added servers invisible, removed servers linger

Bug description

An existing session's view of the available MCP servers/tools is frozen at session creation and never converges with the live MCP configuration:

• Added server is invisible to existing sessions. After adding a new MCP server, sessions created before the addition never learn the new server's tools exist. The /mcp command correctly lists the server as available, but the model in an existing session has no context (no tool specs, no prompt-level mention) that the new tools can be called.
• Removed server lingers as stale context. Conversely, a session created while an MCP server was configured keeps that server's tools in its conversation context after the server is removed. /mcp correctly no longer lists it, but the model still believes the tools exist and attempts calls, which fail with mcp call failed: MCP server "<name>" unavailable after reconnect on every attempt (observed with an osv server: get_vulnerability failed repeatedly while a sibling fetch server kept working).

The client-facing /mcp surface and the model-facing tool surface disagree in both directions — the session catalog appears to be assembled once (per-session catalog over the shared global MCP manager) and never refreshed or re-announced when the global manager's server set changes.

Steps to reproduce

1. Start mecated/mecatui with MCP servers A and B configured; create a session and converse so the session holds context.
2. Remove server B (or make it unavailable) and add a new server C.
3. In the same session, run /mcp: it reflects the new truth (C listed, B gone).
4. Ask the model to use a tool from C: it does not know C exists.
5. Ask the model to use a tool from B: it attempts the call and gets MCP server "B" unavailable after reconnect; nothing informs the model that B was removed rather than transiently failing.

Expected behavior

An existing session should converge with the live MCP server set, or at minimum the model should be told about the divergence:

• Tools from a newly added server become callable (and discoverable by the model) in existing sessions, or the session is explicitly told a refresh/new session is required.
• Tools from a removed server are withdrawn from the session's advertised catalog, and a call to a removed tool returns a model-visible result distinguishing "server removed from configuration" from a transient connection failure.

Per the AGENTS.md rule, a model-facing affordance that depends on model behavior needs a model-visible instruction — a stale tool surface with no signal fails that discipline in both directions.

Actual behavior

• Existing sessions never see tools from servers added after session creation, even though /mcp lists them.
• Existing sessions keep advertising tools from removed servers; calls fail with a generic unavailable after reconnect error that reads as transient, so the model retries a permanently-gone server.

Environment (if relevant)

• OS/version: macOS (darwin)
• mecatl version or commit: main @ ebb14c788
• Deployment shape: mecatui (in-process mecated)

Additional context

Likely touchpoints: the per-session catalog assembly over the shared global MCP manager (internal/app/catalog.go assembleCatalog / sessionEngineFactory) and the "reused-not-reconnected" global manager contract — per-session catalogs are built once from catalogAssets and there is no re-assembly or model-visible announcement when the manager's server set changes mid-session.