[Feature]: Opt-in automatic cleanup of retired worktree and branch indexes

[giancarloerra]

Problem or motivation

Temporary worktrees and branch-aware indexing can leave separate Qdrant indexes behind after the worktree or branch is retired. codebase_prune supports explicit reclamation, but repeated cleanup remains manual.

Proposed solution

Add optional automatic cleanup of retired local indexes, disabled by default. A merge alone must not trigger deletion: the branch or worktree may still be in use.

Initial scope:

• Restrict automatic cleanup to explicitly local, non-shared indexes with verified ownership.
• Require verified worktree removal or branch deletion, not merely a branch switch, merge, or missing local directory.
• Record enough original repository, branch and worktree association to identify retired indexes without guessing from collection names. Existing records without sufficient evidence remain report-only, with no reset or migration required.
• Preserve shared/pinned identities, active writers and ambiguous or inaccessible records.
• Reuse the existing prune inventory, writer barriers, resource deletion and post-deletion verification.
• Remove only index resources and associated metadata, never source directories or Git branches.
• Report deletions, refusals and incomplete cleanup explicitly.

Acceptance criteria

• Existing behaviour is unchanged unless the option is enabled.
• Retiring an eligible worktree or branch removes only its index resources; the main index and unrelated indexes remain intact.
• A merge or branch switch alone removes nothing, including after a squash merge.
• Missing metadata, unavailable mounts, permission errors and active writers never authorize deletion.
• Repeated cleanup is safe, and deletion failures remain visible.
• Tests cover retirement, retention, concurrent writers and partial failures.

Alternatives considered

Continue explicit codebase_prune cleanup. Shared Qdrant remains under explicit operator-controlled reclamation for the initial version.

Area

Indexing, MCP tools / API

Additional context

Follow-up to #167, which introduced explicit reclamation rather than automatic cleanup.