Agent rename does not notify running agents: AGENTS.md update invisible mid-session

[cameronhotchkies]

Summary

When an agent is renamed via the settings dialog, AGENTS.md is regenerated on disk immediately — but running agents are never notified. Any agent with an active session continues using the old name for @mentions until their next new channel session starts.

Root Cause

update_managed_agent (agent_models.rs:783-981) explicitly does not restart the agent:

// agent_models.rs:785
/// Does NOT auto-restart the agent. Runtime config changes (system prompt,
/// parallelism, commands, toolsets) take effect on the next agent spawn.
/// Name changes are synced to the relay immediately via a kind:0 re-publish.

After the rename:

• AGENTS.md at ~/.buzz/AGENTS.md is regenerated with the new name (try_regenerate_nest at line 953)
• No Tauri event is emitted to the desktop frontend or to running ACP processes
• No IPC signal reaches running buzz-acp processes
• agents-data-changed is only emitted for persona operations (personas/mod.rs:580, 681) — never for update_managed_agent

In buzz-acp/src/pool.rs, agent_core (the NIP-AE core memory section) is cached per channel session (lines 1119-1157, core_sections HashMap). The comment at line 1119 says:

// Per Tyler's locked spec: NO mid-session refreshes. Re-fetch only
// happens when a session is invalidated and recreated.

AGENTS.md is a filesystem file, not injected through the ACP context pipeline. Agents read it on their next turn by consulting the file directly, but they have no signal to do so proactively.

Concrete Scenario

1. Agent "Varys" is running with an active session in channel X
2. User renames agent to "Osmosmith" — AGENTS.md updated on disk, kind:0 re-published
3. Varys/Osmosmith's next turn in channel X: still has "Varys" in its context because the session was not invalidated
4. Other running agents (e.g. Timpani) have AGENTS.md updated on disk but won't act on it until their next turn where they explicitly re-read the file, or their next new session

Affected Code

• desktop/src-tauri/src/commands/agent_models.rs:783-953 — no emit, no restart signal after rename
• desktop/src-tauri/src/commands/personas/mod.rs:580,681 — agents-data-changed only emitted here, not in agent_models.rs
• crates/buzz-acp/src/pool.rs:1119-1157 — core_sections cache; no invalidation path from rename

Suggested Fix

Two options, not mutually exclusive:

Option A — Emit an event on rename: After a successful rename + AGENTS.md regeneration, emit a Tauri event (e.g. agents-data-changed or a new agent-renamed event). The ACP harness could listen for this and invalidate the affected agent's sessions, triggering a core re-fetch on the next turn.

Option B — Session invalidation on name change: When name_changed is true in update_managed_agent, signal the running ACP process for that agent to invalidate its channel sessions. This forces a re-fetch of core (and a re-read of AGENTS.md from the base prompt path) on the next turn.

Either fix ensures other running agents pick up the new name within one turn rather than waiting for an organic session rotation.

Relationship to #1822

This is a separate issue from the silent relay sync failure (#1822). Even if the relay sync succeeds, running agents are still unaware of the rename until session boundary.

Discovered via

Investigation of agent identity rename not propagating (related to #1743).