feat(memory): Badness-score abort victim selection in SharedArbitrator

[jaylisde]

Motivation

Today's abort victim selection is lexicographic: priority first, then capacity bucket, then age. Priority acts as a hard wall — no amount of capacity difference can override even a 1-step priority gap. This change converts a priority step into a bytes-equivalent and adds it to capacity, so a large enough capacity difference can punch through a small priority gap. The weight knob controls how hard the wall is: a large weight keeps priority dominant, a small weight lets capacity matter.

Problem

With the current hard-wall ordering, three issues arise when capacity is unevenly distributed:

1. Any priority gap gives absolute protection. A large query with even 1 step higher priority is completely shielded from abort, regardless of how much memory it holds. The capacity difference is ignored because priority dominates unconditionally.

2. Wasted aborts that don't satisfy the reclaim target. The arbitrator kills lower-priority queries one by one. If each is smaller than the target, no single abort satisfies the request — so the cascade continues until enough queries are dead.

3. Excessive collateral damage. Multiple small queries are killed when a single large query could satisfy the reclaim target in one abort — but is never considered because of its priority.

Implementation

Replace the legacy lexicographic victim selection with a single badness-score mechanism:

score = currentCapacity + priority * (priorityWeightPct * arbitratorCapacity)

• Capacity term uses currentCapacity (abort frees the whole pool).
• Priority weight (abort-priority-weight-pct, default 1.0) is the exchange rate between priority and capacity — how many bytes one priority step is worth, expressed as a fraction of arbitrator capacity. This keeps the config portable across deployment sizes.

Default behavior: the default weight (1.0) preserves priority dominance — a higher-priority query will not be aborted before lower-priority ones. Lowering the weight (e.g. 6.25%) lets capacity override small priority gaps across groups.

Behavioral difference from legacy within the same priority group: scoring picks the strictly largest candidate first, with age as tie-break when capacity is equal (younger aborted first). Legacy used capacity bucketing which could skip larger candidates in favor of younger ones within the same bucket. The largest candidate is always considered first, reducing the number of abort rounds needed.

Before vs After

Setup: 1 GB pool, 6 queries, arbitrator needs to reclaim 300 MB. big_etl (priority=1, 600 MB) is only 1 priority step above 5 small queries (all priority=2, totaling 340 MB).

Results:

	Before (legacy)	After (scoring, weight=6.25%)
Victim selection	priority=1 absolutely protected	600 MB capacity outweighs 1-step gap
Aborts to satisfy 300 MB	5	1
Queries surviving	1/6	5/6
MB reclaimed per abort	68 avg	600

Scoring breaks the absolute priority shield, eliminates wasted cascade aborts, and reduces collateral from 5 killed queries to 1.