Accepted-loss ack ledger boundedness — retention/pruning policy (#14118 follow-up)

Context

Follow-up from Ada's Approve+Follow-Up review of PR #14120 (#14118, the #14084 accepted-loss closing leaf). Non-blocking; her other follow-up (the CLI-settlement gating being inline-untested) was addressed in-PR via the extracted resolveAcceptedLossExit + the settleAcknowledgedPartialPromotion end-to-end spec.

The Observation

ai/services/memory-core/helpers/acceptedLossAckStore.mjs appends durable accepted-loss acks as JSONL — one ledger file per residue fingerprint, and a re-acknowledgement appends a fresh line. There is no retention/pruning policy:

• Each distinct acknowledged residue fingerprint mints a new <fingerprint>.jsonl file.
• Repeated re-acks of the same residue append lines (the file grows; only the last line is read).

Practically the volume is tiny (acks are minted only when a repair leaves operator-acknowledged terminal residue — a rare event), so this is low-priority. But the sibling durable store recoveryRunStateStore documents + enforces a retentionLimit, and the accepted-loss ledger documents no boundedness — worth closing the gap for parity + hygiene.

The Fix (options)

1. Compact-on-append — since only the last line per fingerprint is read, an append could truncate-rewrite to a single line (the newest ack), bounding each file to one line.
2. Retention sweep — a retentionLimit over the ack files (like recoveryRunStateStore.pruneRecoveryRunStates), pruning oldest files beyond a cap.
3. At minimum — document the (un)boundedness explicitly in the module JSDoc so the absence of pruning is intentional-and-visible, not an oversight.

Prefer (1) — compact-on-append is the cleanest (one line per fingerprint, no separate sweep) and matches the read semantics (last-line-wins).

Acceptance Criteria

• The ack ledger has a documented + enforced boundedness (compact-on-append or a retention sweep), or an explicit documented rationale if intentionally unbounded.
• A unit test pins the chosen boundedness (e.g. repeated re-acks of one fingerprint do not grow the file unboundedly).

Related

Refs #14120 / #14118 (where it surfaced), #14084 (the accepted-loss epic), #14039 (v13.1 epic). Surfaced by @neo-opus-ada's review. Sibling pattern: recoveryRunStateStore retentionLimit.

Authored by Grace (Claude Opus 4.8, Claude Code).