fix(cascade): record which beat lost the optimize commit race

[gloryfromca]

What

Adds one field — pruned — to the benign commit-conflict log:

[debug] cascade_lancedb_optimize_conflict  kind=episode  pruned=True  error='...'

No behaviour change. Log level stays debug, the failure streak is still not
incremented, and no fallback rebuild is triggered.

Why

Lance labels both maintenance beats' commit identically:

This Rewrite transaction was preempted by concurrent transaction Delete at version 3622

Light beat (optimize()) and heavy beat (optimize(cleanup_older_than=…)) are
both Rewrite transactions, so the message cannot tell them apart. The costs do
not match:

lost beat	cost
light	free — compaction retries ~10s later
heavy	that table skipped a whole prune cadence; superseded files stay on disk

So a run of heavy-beat conflicts is exactly what precedes an index dir growing,
and today it is indistinguishable in the logs from harmless light-beat noise.

This is not hypothetical. During the storage soak one table's cleanup went
quiet for 13 minutes with zero failures logged (optimize_failed,
write_lock_deadline_exceeded, maintenance_task_timeout all 0) while
prune_stale_seconds climbed linearly. Establishing that those were lost heavy
beats meant back-inferring beat types from the 300s cadence, then two 35-minute
debug-level reruns (~870MB of logs) to confirm. With pruned it is a grep.

The sibling failure log already carries pruned=should_prune; the conflict
branch in the same except simply missed it, and the variable is already in
scope.

Test

test_conflict_log_names_the_lost_beat drives both beats in one run (frozen
clock, so beat selection does not depend on runner uptime) and asserts the
heavy beat's conflict logs pruned=True and the light beat's pruned=False.

Mutation-verified: removing the field fails the test with KeyError: 'pruned'.

tests/unit/test_memory/test_cascade/ — 202 passed, 0 skipped. make lint clean.

🤖 Generated with Claude Code