fix(mcp): rebuild the prompt prefix when the connector set changes

The `## MCP servers` table lives inside the frozen system prefix, which
PrefixCache holds for twenty idle minutes. Refreshing a user's global-access
snapshot fixed what `mcp.tools()` offers but left the table describing the
world before the change, so an admin could enable a connector, ask for it in an
open conversation, and be told in good faith that it does not exist — with the
tools sitting right there. Same gap on a reinstall, whose new
llm_short_description reached the runtime and not the prompt.

Both refreshes now call `invalidate_prefixes()` on the live contexts they were
already iterating, the seam the skill tools use. Order matters and runs against
the intuition: `render_mcp_list` renders the runtime's in-RAM state, not the
DB, so the invalidation goes last — after the snapshot refresh and after the
servers restart. Rebuild earlier and the prefix is repopulated from the very
descriptions being replaced, with nothing left to invalidate it a second time.
In the reinstall that means waiting out a dependency install; those users were
already reading a stale table, and an early rebuild would only freeze the stale
one in place.

Also warn when a feed's connector.json and index disagree on the integer
version. The manifest silently wins, so if the index is the lower of the two
the strict `feed > installed` comparison is false forever: the connector never
offers an Update and nothing anywhere says why.

CLAUDE.md

@@ -394,7 +394,9 @@ Same economics, other end of the request. `AgentSystemContext::system_context` i
 
 The refresh rule is the only one that is free: **rebuild once the conversation has been idle longer than a provider's cache could survive** (`PREFIX_TTL`, 20 min). The clock is therefore *idle time of this conversation*, not time since a file changed, and reading restarts it — every `get` is a request about to go out. The asymmetry that sets the constant: below a provider's window you pay misses that buy nothing, above it you only pay freshness.
 
-**Writes are deliberately not reacted to, and there is no bus variant for this.** When the agent itself edits an injected file the content is already in the context — its tool call and result sit two messages downstream — so refreshing would repeat what the model just said. A write from *elsewhere* (the same user's Telegram session, a cron job, another member editing `shared-memory/`) is genuinely invisible until the TTL: that is the case where an immediate rebuild costs the most, since a conversation that would notice is by definition a warm one, and the cheaper freshness path already exists — the agent can `read_file`, and a tool result *appends*, which invalidates nothing. The injection header says so in words. Cross-user invalidation would need a `SystemEventBus` variant plus a subscriber per user (the writer lives in a different `UserContext`); it is future work, and this type's key is the seam for it. Note `base` is frozen **whole**: freezing the memory files while letting `__USER_PROFILE__` move would invalidate just as much. The cost is that an `AGENT.md` edit lands at the next rebuild rather than the next round.
+**Writes are deliberately not reacted to, and there is no bus variant for this.** When the agent itself edits an injected file the content is already in the context — its tool call and result sit two messages downstream — so refreshing would repeat what the model just said. A write from *elsewhere* (the same user's Telegram session, a cron job, another member editing `shared-memory/`) is genuinely invisible until the TTL: that is the case where an immediate rebuild costs the most, since a conversation that would notice is by definition a warm one, and the cheaper freshness path already exists — the agent can `read_file`, and a tool result *appends*, which invalidates nothing. The injection header says so in words. Cross-user invalidation of a *file* write would need a `SystemEventBus` variant plus a subscriber per user (the writer lives in a different `UserContext`); it is future work, and this type's key is the seam for it. Note `base` is frozen **whole**: freezing the memory files while letting `__USER_PROFILE__` move would invalidate just as much. The cost is that an `AGENT.md` edit lands at the next rebuild rather than the next round.
+
+**What *is* invalidated eagerly: the two generated lists, because a stale one makes the model deny a tool it has.** The TTL is right for injected content the agent can re-read on demand and wrong for an inventory — a model that reads "no such connector" in the `## MCP servers` table does not go looking, it answers the question. So `Skald::invalidate_prompt_prefix` (the skills door, called straight from `skill_register`/`skill_delete`) has two MCP siblings, both looping the `all_live()` they already had: `refresh_global_mcp_access` — the admin enabling or re-granting a global connector, where refreshing the access snapshot alone fixed what `mcp.tools()` *offers* while leaving the table describing the world before it — and `refresh_connector_after_reinstall`, where a reinstall's new `llm_short_description` reached the runtime but not the prompt. **Order is load-bearing and opposite to the intuition**: `render_mcp_list` renders the live runtime's in-RAM state, not the DB, so the invalidation goes **last**, after the snapshot refresh and after the servers restart — rebuild the prefix first and it is repopulated from the very descriptions being replaced, with nothing left to invalidate it again. In the reinstall that means waiting out a global dependency install that can take minutes; correct anyway, since those users were already reading a stale table and an early rebuild would only freeze the stale one in place. The price is a provider cache miss on the next turn of every open conversation of every live user — cross-user by nature, since one admin is changing something for other people, and there is no cheaper direct path the way there is for a user editing their own memory. It buys back the failure the skills doc-comment already describes word for word.
 
 ## Approval gate