Bound retained Memory Core repair parking and retire stale abort predicate

Context

Vega approved #14066 with three non-blocking follow-ups. The core #14062 repair fix is merge-eligible, but two cleanup points should not remain review-thread-only:

• anyRepairAborted() is no longer used by the production CLI path after #14066 switched operator status to anyRepairNonClean(). It is still exported and unit-tested on the #14066 branch, but a direct tree grep of origin/codex/14062-memory-core-partial-repair-promotion found no production consumer.
• Partial promotion intentionally retains the parked source collection via deleteParking: false / parking-retained, but repeated partial runs can create timestamp/uuid parking collections. The retention/boundedness behavior needs to be explicit instead of incidental.

Duplicate sweep:

• Latest-open issue sweep at 2026-06-26T05:45Z found adjacent #14062, #14023, #14027, #14030, but no issue for retained parking boundedness or anyRepairAborted retirement.
• KB sweep for partial-promoted, retained parking, anyRepairAborted, and cleanup found no existing technical context/ticket.
• Targeted GitHub search syntax failed through gh search issues; the live latest-open issue list still covers the active v13.1 queue and shows no duplicate.

The Problem

#14066 correctly makes partial promotion durable but non-clean: recovered rows become available, unrecoverables stay auditable, and the CLI exits non-zero. That leaves two follow-up hygiene risks:

1. A stale exported predicate can confuse future readers into thinking aborted-only is still the operator status contract.
2. A retained parked collection is a recovery asset, but without a documented bound or cleanup rule it can become long-term Chroma shadow state.

The Fix

1. Decide whether anyRepairAborted() should be removed, made private to tests, or explicitly documented as a compatibility/test seam. Prefer removal if no production consumer exists after #14066 merges.
2. Define the retained-parking lifecycle for partial-promoted Memory Core repair:
   • what collection name pattern is retained;
   • whether a subsequent repair run overwrites, reuses, or accumulates retained parking;
   • what cleanup command/path is safe after operator recovery;
   • what state marker points to the retained parking collection.
3. Add focused unit coverage or source comments so the lifecycle is visible to future repair work.

Contract Ledger

Acceptance Criteria

• anyRepairAborted() has either a proven retained consumer or is removed/retired.
• Partial-promoted retained parking has a documented cleanup/boundedness rule.
• Tests or comments cover the retained-parking lifecycle enough that future defrag work does not delete or accumulate it accidentally.
• #14066 / #14062 note of record links the intended immune behavior: partial-promoted exit 1 -> supervised failure escalation -> operator page.

Related

Refs #14039 Refs #14066 Refs #14062 Refs #14061

Origin Session ID: 019efe4c-5d55-76c0-aba5-665f86d9cbdc