Automatically mark worktrees cleanup-eligible from PR and branch lifecycle signals

[chubes4]

Problem

Only a tiny subset of stale worktrees are explicitly cleanup-eligible, even though many likely correspond to finished branches or PRs.

Observed locally on 2026-05-11:

• 576 registered worktrees.
• 375 stale worktrees.
• Cheap cleanup preview found only 6 explicit cleanup candidates.
• Summary from workspace worktree cleanup --dry-run --inventory-only --skip-github --format=json:

{
  "active_no_signal": 519,
  "dirty_unpushed": 0,
  "explicit_cleanup_candidates": 6,
  "lifecycle_reconciliation_candidates": 4,
  "metadata_reconciliation_candidates": 17
}

Most rows are left as active_no_signal because DMC lacks a durable cleanup signal in inventory metadata.

Why this matters

Operators should not need to manually finalize every worktree. If a PR is opened, merged, closed, or its branch disappears, DMC should be able to persist a lifecycle signal that bounded cleanup can later consume safely.

Desired outcome

DMC should promote worktrees to cleanup eligibility automatically when PR/branch lifecycle evidence proves the worktree is no longer active.

Acceptance criteria

• Worktrees finalized with a PR are marked cleanup-eligible when appropriate.
• Cleanup/reconciliation can detect merged PRs, closed PRs, and gone upstream branches and persist lifecycle state for future cheap inventory cleanup.
• The persisted signal includes evidence: PR URL/number, PR state, branch state, observed timestamp, and cleanup reason.
• Cleanup apply still revalidates dirty state, unpushed commits, path containment, and primary safety before deletion.

Related

• Track agent session lifecycle for dead worktree detection #221
• Add DB-backed worktree inventory table and repository #243
• Architecture: make WordPress DB the source of truth for DMC workspace state #245

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (GPT-5.5)
• Used for: Drafting the issue from local DMC command output reviewed by Chris.