deadline_cluster_ledger

Idea: Earliest-deadline backscheduling on a worst-case "rush now" clock, filling each forced launch with the confirmed striker whose predicted blast point catches the most other uncovered strikers, and ignoring every unidentified track outside id range.

Name: deadline_cluster_ledger (defender)

How it works ------------

1. Track filter. Every track gets an alpha-beta filter, blended with the reported velocity, because sigma=6 noise makes raw positions useless for blast-geometry prediction. A classification, once seen, is remembered.
2. Threat set. Threats are confirmed strikers, plus unknown tracks already inside id_range. Decoys are never engaged. Unknowns parked outside 150 are never engaged either. This means baits, magazine-drain rings and decoy screens cannot spend a single interceptor.
3. Coverage ledger. For each interceptor in flight, the bot solves the intercept from that interceptor's own position. Its target, and every threat predicted to be inside about 0.8 blast radii of the detonation point, gets a survival factor of 0.15. Covered tracks drop out of the queue.
4. Worst-case deadline. Each uncovered threat gets a launch deadline: the last tick at which an interceptor could still meet it outside radius 45, assuming it turns and rushes straight in at full speed right now. Loitering therefore never hides a threat's real deadline.
5. Earliest-deadline-first capacity test. Threats are sorted by deadline, and only the first min(threats, stock) count. If waiting one more tick would leave fewer launch slots (2 per tick) than the threats due by the k-th deadline, the bot must fire now. It picks, among the threats due by that binding deadline, the one whose predicted blast point holds the most other uncovered threats. Otherwise the bot holds fire, so the swarm keeps converging and later shots catch more drones each. Outside the forced case it also fires opportunistically when a single blast is predicted to catch three or more threats (or two or more close in).
6. Retargeting. An interceptor whose target died or turned out to be a decoy is sent to the uncovered threat it can reach soonest.
7. Gun. Every tick the gun fires at the nearest uncovered threat in range. If all threats are covered, it fires at the nearest threat anyway, as insurance against the 15% interceptor miss rate.

Why it holds up against the whole field ---------------------------------------

• synchronized_ring and phase_locked_ring. Both park strikers just outside the id gate, then cross it together. The worst-case deadline already accounts for loiterers, and the capacity test counts all of them at once. Launches therefore start exactly when 2 per tick is barely enough. They are never late, which is what killed the ledger-style bots. And because waiting is legal until that moment, the late shots land where the ring has contracted, so many blasts take two drones.
• interleaved_shell_ring. Its spacing defeats blast pairing far out. But the queue is ordered by deadline, so the inner shell is served first, the next shell second, and so on, at the full launch rate. Bots that hold for clusters that never form get flooded; this one does not. Pairing kicks in automatically once the convergence geometry brings drones within a blast radius near the asset, and the gun handles leakers.
• depth_shell_saturation and trickle. Staggered depths simply become staggered deadlines. Each threat is engaged on time and individually, and there is no premature magazine dump on far shells.
• parked_ring_magazine_drain, decoy_screen, staggered_screen_trickle, flanker, multi_axis. Nothing is fired outside id range or at decoys, so draining fails. Flanks and multiple axes are bearing-agnostic to a deadline queue.
• rush. Many threats with short deadlines immediately trigger the capacity rule at the maximum rate, and blast packing helps on the dense front.