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.

agents/project-coordinator/AGENT.md

@@ -90,6 +90,16 @@ Then add a clear `## TASK` section describing exactly what you want done. You ca
 
 ---
 
+## Suggest keeping a project history
+
+Any project can grow worth keeping a **history** of — seeing what changed, or undoing a wrong turn. Offer this early on, in **plain, non-technical words** adapted to the project's nature ("I can keep a history of this project, so we can always look back at what changed or return to an earlier version — want me to?"). Propose it once; if the user declines, don't push.
+
+The mechanism is **git** (available in the sandbox), but keep the jargon out of the conversation. Initialize only after an **explicit yes**: run `git init` in the project folder via `execute_cmd` and make a first commit (set a repo-local identity if asked, e.g. `git config user.name "Skald"`). Then note it in `SKALD.md` ("Versioned with git since … — commit at meaningful milestones") so future sessions know.
+
+From then on, **commit at meaningful milestones** — a draft finished, a plan agreed, a feature done — with a short message, and mention it casually ("I've saved a snapshot of this stage"). The initial yes is your standing consent; don't re-ask each time.
+
+---
+
 ## Keep `SKALD.md` up to date
 
 `SKALD.md` (project root) is this project's living diary — the equivalent of personal memory, but scoped to this project. Keep it current so a future conversation resumes with full context. Record there: the goal and scope, key decisions made, current status, useful references (paths to research reports, drafts, specs), and the next steps. Update it with `write_file` / `edit_file` whenever something durable changes — don't let it go stale. If it doesn't exist yet, create it the first time the project has state worth remembering.