de_forge is terrorist-sided: T win 62% of rounds there and 47% on de_cinder, with the same bots #154

Find out why the map everybody plays hands the terrorists three rounds in five, and fix the thing the measurement blames — then prove it with the same run.

#146 landed as pull #149 and the round report can finally say who won. The first thing it says, at a3d302b, twenty seeded matches a map, same shipped policy, the person idle:

                 de_forge                      de_cinder
rounds played    145                           131
side split       T 62% (90) · CT 38% (55)      T 47% (61) · CT 53% (70)
plant rate       65%                           52%
ends             det 76 · time 15 · elim 42 · def 12    det 58 · time 8 · elim 55 · def 10
defuse rate      13%                           15%
median round     123s                          97s

Ninety rounds to fifty-five. That is not noise: at 145 rounds an even split has a standard deviation of six, and this is three of them out. And the sides swap at half time in these matches (halfTime is winScore - 1, match.ts:73), so it is the side that wins, not a team that got lucky — and the same bots on de_cinder are within a coin flip. Whatever is wrong is about de_forge, not about the policy.

de_forge is the default map, the map the policy was trained on, and the one every new visitor plays.

Done looks like:

• [ ] The diagnosis comes before the change, with numbers. Say which of these it is, out of the data rather than out of a hunch: the bomb goes down too easily (65% against 52%), the retake never arrives (12 defuses in 95 plants), or the counter-terrorists lose the opening fight (42 eliminations). Pull #147's cell-distance argument is the model — it counted how far each spawn is from each site and drew a conclusion.
• [ ] The fix is in whatever the diagnosis blames, and only that: the layout's areas-and-crates tables if it is geometry, plan.ts's counter-terrorist side if it is where they stand. No per-map special case and no retraining — both of those are other issues.
• [ ] After, the same command: de_forge's side split within ten points of even over at least 140 seeded rounds, stated with the seeds and match count, while plant rate stays between about 55% and 70% and the median round stays at or under 130s. A map where neither side can plant is not balanced, it is broken.
• [ ] de_cinder is untouched and re-measured anyway, to show it did not move.
• [ ] The structural tests (map.test.ts, which now walks every map in MAP_NAMES) stay green; if a route or a site moves, they are what proves the map is still whole.

Files: src/client/map.ts (the de_forge tables) or src/client/plan.ts, plus README.md if the map's description changes. Not both files unless the measurement says so.

Risks: this is the map the shipped weights were trained on — a big geometry change makes CARD.winRate (72%) less true, which is #150's territory. Prefer the smallest change that moves the number: a crate, a doorway, a spawn a few cells back. And do not run this beside #46: a counter-terrorist that actually defuses moves this exact number, so whichever goes second must re-measure first — it may find its job already done.

Crew: vesper — reading a layout for why one side wins is exactly the brief, and the measurement is already in the repository.

The 62% is one sample, and the rest of the samples disagree — so what done looks like here changes. Measured today on main at 75febb4, the same shipped policy, normal bots, the person idle, through the same scripts/measure.ts:

Four runs of the same map and the same bots spread from 48% to 62%. There is probably a real terrorist edge on de_forge of a few points — three of the four runs lean T, and the geometry argument in the body is sound — but 62% is the top of the range and not the number to carve a map to. A builder handed this issue as written would move walls until one seed read 50%, which is fitting the layout to a table: exactly what Measuring the round refuses to do for the plant rate.

Rewritten — done now looks like, in this order:

• [ ] Establish the number before changing anything. Pool several seeds into one measurement — scripts/measure.ts takes a single --seed today, so this probably wants --seeds (or a loop in the script that reports the pooled total), in the spirit of what #165 just added beside it. Report rounds played and the split with an interval, not one percentage.
• [ ] Say what the idle person does to it: the README already notes the count is effectively 5-on-4 for the terrorists in the first half and an idle terrorist in spawn after the swap. Either measure with both sides' bots only, or quantify the asymmetry, so the split being blamed on the map is not partly the empty chair.
• [ ] If the pooled split is inside a couple of points of even, close this and put the number in the README's table with its interval. That is a real outcome and the cheapest one.
• [ ] If it survives — say, T above 55% over several hundred rounds — then change the one thing the measurement blames, re-run the same pooled protocol, and show both tables in the pull. One geometric change, not a tuning session.
• [ ] Either way map.test.ts's structural claims still hold for both maps, and the README's Measuring the round says what was measured and how many rounds it took.

The body above stays as the finding; this comment is the scope. Brief that fits: scout — this is measurement first and geometry second, and the first half is a script change with tests.