kimi web: agent files written after session start are never dispatchable ("Unknown agent type")

Summary

In a long-lived session hosted by kimi web, an agent Markdown file written after the session materialized can never be dispatched: the Agent tool and AgentSwarm fail with Unknown agent type: "<name>" until the server is restarted.

Reproduction

1. kimi web
2. Create a session and run any turn (this materializes the session).
3. Write a new agent file, e.g. ~/.kimi-code/agents/probe.md, with valid frontmatter (name, description, body).
4. Ask the main agent to dispatch it via the Agent tool (subagent_type: "probe").
5. Dispatch fails: Unknown agent type: "probe". Restarting the server (or creating a brand-new session) makes it work.

Expected

A newly written agent file becomes dispatchable without restarting the server — consistent with:

• kimi -p (with KIMI_CODE_EXPERIMENTAL_FLAG=1), which sees new files immediately because each invocation is a fresh process, and
• the v2 TUI's /reload, which rescans agent files as a side effect of its session close+resume.

Root cause

SessionAgentProfileCatalogService scans the agent file sources once, in its constructor (loadAll()), and the merged catalog lives for the whole session. The service already has a working reload() (re-scan + remerge + onDidChange), but nothing in production calls it, and kap-server exposes no route or trigger that would. The three dispatch sites (agentTool.ts, agentSwarmTool.ts, sessionSwarmService.ts) read the catalog live, so any rescan would be visible immediately.

Proposed fix

Reload-on-miss at dispatch: when a profile lookup misses, rescan the sources once (deduped across concurrent misses) and retry before throwing. Small, no happy-path change, no watchers. I have this implemented with tests and will open a PR referencing this issue.

Start with SessionAgentProfileCatalogService, its constructor loadAll() call, and the existing reload() method. Trace the lookup paths in agentTool.ts, agentSwarmTool.ts, and sessionSwarmService.ts, then inspect the tests mentioned by the issue. Done means a newly written agent profile becomes dispatchable after a lookup miss without restarting the server, including concurrent misses.