Session delete removes the archive payload but leaves a stale database row, then errors on every subsequent delete

Summary

Deleting a session (via the session-management delete path) removes the archived session payload from disk but does not remove the corresponding row from the local sessions database. The stale row then causes an error after every subsequent delete operation, and the deleted session continues to appear in listings.

Impact

• Bulk cleanup of old sessions (needed because of rollout-file disk growth — see companion issue) is not practical: each delete leaves an orphaned DB row and surfaces an error.
• Session listings and the on-disk state drift apart over time.

Repro

1. Archive or accumulate several sessions.
2. Delete one via the CLI/session management flow.
3. Observe: payload removed from ~/.codex/archived_sessions/ (or sessions dir), but the session row remains in the local sqlite state DB; an error is reported after the delete completes.
4. Delete another session: the error repeats.

Suggested fix

Make delete transactional across both stores: remove (or tombstone) the DB row in the same operation as the payload removal, and make the operation idempotent so re-deleting an already-removed session is a no-op instead of an error.

Environment

• Codex CLI with Codex Desktop, macOS (Darwin 25.5). Discovered during a disk-cleanup session on 2026-08-01; the delete bug was reproduced by Codex itself during that session.