migrate-to-apilisted

# migrate-to-api You are repeating the shape of PR #3 (the admin-cluster migration). Read commits `16f7693` and `df5ef52` if you haven't — they're the canonical reference for what this migration looks like when done correctly. ## Scope check Confirm with the user which cluster is being migrated. Cluster name should match an existing `server/handler_<cluster>.go` or `server/mcp_<cluster>.go` file set, e.g. `records`, `search`, `sessions`. ## Order of operations Do this in order. Don't skip ahead; each step informs the next. ### 1. Inventory List every operation currently inline: - HTTP routes in `server/handler_<cluster>.go` (note paths, methods, request/response shapes) - MCP tools in `server/mcp_<cluster>.go` or `server/mcp.go` registrations for this cluster - CLI proxy registrations in `cli/mcp_proxy.go` that forward to those routes For each operation, note: lock discipline, whether it does I/O, whether it's destructive. ### 2. Write `api/<cluster>.go` For each operation, follow the `new-operation` skill checklist. Typed Request/Response, `XxxDescription` constant, error helpers from `api/errors.go`, validation caps from `api/validate.go`. Lock discipline: - If the current inline handler holds a lock across I/O, this migration is where you fix that — use the three-phase pattern with a snapshot hook. - If it already has correct lock discipline, just preserve it. ### 3. Add supporting primitives if needed The admin migration added `core.SwapGraph` and `backup.Cre