j127: forced-share allocator (TR_RACK_SHARE, default-off) + allocation batch pre-registration

docs/gun_campaign.md

@@ -977,3 +977,57 @@ The phase-1 conclusion stands and is now joined by the phase-2 one:
 | `/tmp/ab/j123_b1` | `2a98aba` | 270 (0 failed, 0 never started, 0 excluded) | pattern, len6, len16, depth100, rad_offset, rad_scale | `len6` the only rule-2 win (wins +0.49, sign p=0.039); **red flag: all 5 arms wins-positive incl. the bearing-invariant `rad_offset`** |
 | `/tmp/ab/j123_b2` | `1b59b65` | 396 (0 failed, 0 never started, 0 excluded) | pattern, len6, len16, rad_offset | **`len6` does not replicate** (−0.04 wins, p=1; +1.8 dmg, p=0.30); all arms not distinguishable; the incumbent is already tuned |
 
+
+---
+
+## Allocation: is the selector leaving value on the table?
+
+**Question (owner-spotted, 2026-09-26).** The selector's own `/tmp/gun_stats.jsonl`
+(10,608 rounds, 2-gun racks, selector ON) gives Pattern ~66% of selection ticks and
+that *looks* justified by per-shot hit rate. But `GUN_SELECTOR_FLOOR` is a FITNESS
+floor (only ignores a gun below 25% of the best), **not a SHARE floor**: nothing
+guarantees the second gun any share of the shots. The ~66/34 split is an OUTCOME of
+ranking + hysteresis, not a POLICY. **Nobody has ever tested whether a deliberately
+different split beats `pattern` alone.** This batch builds the mechanism
+(`TR_RACK_SHARE`, default-off) and asks directly:
+
+> **Is gun ALLOCATION a lever?**
+
+### Pre-registration (written BEFORE the batch)
+
+* **Mechanism.** `TR_RACK_SHARE=pattern:50,bitbrain:50` (relative weights,
+  case-insensitive `RackGunNames`) replaces `chooseFromFit`'s ranking with a
+  deterministic **deficit round-robin** over the named **ADMITTED** guns. Each
+  allocation is held for `GUN_SELECTOR_DWELL` ticks (turret convergence) so the
+  share is over dwell epochs; selected-tick counts follow the weights.
+  Deterministic (not randomized) because the question is whether a *specified*
+  split is better, the schedule is auditable, and it needs no seed.
+* **Default-OFF parity.** Unset `TR_RACK_SHARE` leaves the weights empty and
+  `selectGun` takes the unchanged ranking path. Parity proven before fighting:
+  `test_gun_harness 39`, `test_rack_membership 48`, `test_selector_tiebreak 19`,
+  `test_env_report 25` — all green at their exact shipped counts.
+* **Panel.** `tools/ab/panel_movement.txt` — the frozen 15-opponent movement panel
+  (never edited). Unit of evidence = number of opponents.
+* **Arms** (`tools/ab/arms_alloc.txt`, 6 arms): `pattern` (reference, shipped);
+  `sel_pb` (selector ON, Pattern+BitBrain, shipped policy = the ~66/34 OUTCOME);
+  `share_5050_pb`; `share_7030_pb`; `share_5050_pt` (TMHorizon); `share_5050_pk`
+  (KNN). Movement pinned `TR_MOVEMENT=strafe` in every arm.
+* **Judge on damage/run and ROUND WINS** (standing rule); hit rate and distance
+  are explanation. Per-opponent deltas vs the reference; CI, sign test, sign-flip
+  permutation, MDE.
+* **Decision rule (pre-registered).**
+  1. If a **forced-share arm beats `pattern`** (CI excluding 0 **and** sign-flip
+     p<0.05) → **ALLOCATION IS A LEVER**; the selector was leaving value on the
+     table and the next job tunes the share.
+  2. If **no forced-share arm beats `pattern`** → the ~66/34 allocation was
+     already right; the rack question is genuinely CLOSED.
+  3. Either way, report whether the forced arms differ from `sel_pb` — that
+     isolates `policy` from `gun choice`.
+* **Allocation evidence.** Per arm, the **applied share** (from each run's
+  `gun_stats.jsonl` `selected` counts) and **each gun's per-shot hit rate**
+  (realShots/realHits, same battles). Per-shot hit rate is the right signal HERE
+  because the movement is identical inside a battle.
+
+### RESULTS
+
+_(filled in after the batch)_