[LUOaini1213]

Deleting an Agent could remove its database record and then fail to clean up files, leaving retry requests at 404 and orphan traces able to block the next startup. Even with durable recovery, the browser discarded cleanupPending, so users saw the Agent disappear without knowing that cleanup still needed attention. The PR makes deletion recoverable and exposes its pending, retry and completion states in the UI.

Removal journals a fixed cleanup intent in the same database mutation. A deletion gate blocks Start, edit and message admission, including previously queued mutations, and settles already admitted edits/publication before cancellation and archive. Deleted Runs are excluded from OTLP scheduling, including queued checkpoint writes. Queue removal, span removal and workspace archive progress independently; failed steps retry every five seconds and at startup. Concurrent DELETEs share the intent and archive destination. Rename-before-ack recovery and migration of legacy orphan traces preserve healthy HTTP/OTLP startup.

The authenticated GET /api/deletion-cleanup projects only pending IDs, kind and Run count. It never returns the journal, paths, prompts or credentials. The browser discovers pending work after a reload and polls it serially. A synchronous retry lock prevents duplicate clicks; retry uses the row's own ID and first confirms that it is still pending and no live Agent has that ID. A retry 404 counts as completion only after two fresh successful reads confirm absence. Unavailable, malformed or unauthorized responses preserve an unknown/last-observed state. Versioned reads cannot overwrite a newer deletion receipt or publish a false completion notice. Deletion also invalidates earlier Agent-list reads. Legacy servers remain compatible, without claiming a cleanup guarantee that their response cannot establish.

npm run build && npm run demo:cleanup starts a loopback-only instance with disposable temporary JSON/workspace files and a runner that forbids model calls. The first DELETE and background archive attempts inject EACCES into this instance's archive method; the next manual DELETE lifts the injection and performs the actual archive. It changes no OS permissions and no production state. The real browser can show pending cleanup after reload, retry it and display the completion receipt. The process removes only its validated temporary directory when stopped.

Validation at 852398c410ee9d7f03979f41e132f3aa2a944326:

• Local Node 24.18.0 / Windows npm run check passed: 261 tests (3 contract, 185 server, 73 web), all type checks, production builds, built-server smoke, Replay HTTP smoke, and actual OTLP HTTP 503/timeout/SIGKILL recovery.
• New focused coverage includes authenticated real HTTP/JSON restart discovery under injected EACCES, explicit privacy allowlists, 23 controller/render cases, malformed responses, legacy status, 401, duplicate retries, a live-ID conflict, dropped responses, orphan traces and a real deferred stale-read regression. Independent read-only review reproduced the timing concern and verified the correction; five independent in-memory timing probes passed.
• Actual browser QA exercised the loopback built app: initial DELETE returned pending with the Agent record absent and the original workspace present; reload recovered the pending row. Clicking Retry returned complete, left one actual archive, and cleared both persistent and API pending records. The completion notification appeared, and a subsequent reload showed no cleanup panel. At 390 x 844 the document width was 375px; no horizontal overflow or console errors was observed. Pending, completed and mobile screenshots were saved.
• Demo syntax and git diff --check passed. Existing source-pinned OTLP benchmark artifacts were unchanged. No model, paid inference or new performance measurement was run.

Latest-head push CI and PR CI completed successfully on Node 22.23.3 and 24.21.0. All four jobs confirm 261 tests passed with zero skips, type checking, build and every smoke passed; real OTLP recovery reports identical restored payloads, no resend of the acknowledged Run and published per-Run acknowledgments. The exact head above remains a draft PR, unmerged.

The journal retains the original single-process atomic-rename persistence assumptions; it adds no power-loss or multi-writer guarantee. Collector ingestion accepted before cancellation cannot be retracted. A corrupt or unwritable main database can still prevent startup. Underlying filesystem access must be restored for ordinary pending cleanup to finish; the demo's failure is explicitly controlled injection. See docs/DELETION_RECOVERY.md for the recovery, status and compatibility contract.