historian redundancy skip waits on queued drops that can only land on the bust the skip suppresses (session stuck from proactive floor until usage outgrows the projection) #524

Seen live on v0.42.6. The logic is unchanged on master 9db0faee5 (compartment-trigger.ts:758-765, :638-647; cache-busting-signals.ts hasReclaimRide).

What happened

A primary session (execute threshold 63%, proactive floor 61%) queued a large ctx_reduce at 12:49:24Z (69 pending ops). From 12:54:36Z to 13:23:46Z, every one of 54 transform passes logged the same pair:

historian redundancy skip: summarizer not needed this pass — usage is 61.0%; queued/automatic drops are projected to reclaim to 36.1% (target 47.3%) on the next eligible execute pass
pending ops held — reason=no originating cache-bust opportunity; scheduler=execute, historianRunning=false

Usage climbed from 61.0% to 70.2% while the projection crept from 36.1% to 47.2%. The historian finally fired at 70.5% only because the projection crossed the target: compartment trigger: proactive fire at 70.5% (… projected post-drop=47.6% target=47.3%). So for about 30 minutes nothing compacted and nothing was reclaimed. Every turn was served at the full, growing prefix.

Why: two correct rules that wait on each other

1. Drops are ride-only. The pending-op drain is gated by hasReclaimRide = hardFold || force || explicitFlush || publishedHistory. scheduler === "execute" is deliberately NOT a ride. So below the force band (and with no flush or fold), queued drops wait for someone else's bust.
2. The redundancy skip assumes the drops will land "on the next eligible execute pass". It returns shouldFire: false whenever projectedPostDropPercentage <= relativePostDropTarget. Under rule 1, though, an execute pass doesn't land them. Below the force band, the bust that would land them is exactly the historian publish (publishedHistory) the skip just suppressed.

So the skip's premise is stale relative to ride-only reclaim. The session can only get out when usage grows faster than the projection (what happened here), when it reaches the force band, or when the operator runs /ctx-flush. The force-band branch (:638-647) has the same skip, so near the band it depends on the force ride arriving instead.

Paradoxically, a bigger ctx_reduce makes it worse: more queued reclaim pushes the projection further under the target, so the historian stays suppressed longer.

Suggested fix

Count queued drops toward the redundancy skip only when a ride that would land them is available on this pass (or is known to be imminent), not merely because the scheduler says execute. Without a ride, the historian should fire: its publish is the publishedHistory ride, so the queued drops land on the same bust and the session pays for one bust, not zero reclaim.

A test that would catch it: pending ops present, usage between the proactive floor and the force band, no ride signal. Assert that the trigger fires, or that the skip reason names a ride.