give every recipe one shape: a list of output groups

Implements REQ-MAT-OUTPUT-GROUP. A recipe had two shapes -- outputs produced
together, or outputs of which exactly one happened -- and every rule over them
was written twice, selected by `building == ReprocessingPlant`: sizing a
buffer, deciding whether a cycle fits, resolving what a cycle makes, costing an
item. RecipeDef now holds output groups, each a weight and a list of items, and
a cycle yields exactly one group. One group is the ordinary recipe, so the old
two cases are the same shape with one and with several, and all four rules
collapse to one expression apiece with no building-type test left.

rollReprocessingOutput becomes rollOutputGroup, where a single group returns
without drawing or testing eligibility. That early-out is load-bearing twice
over. Drawing there would consume entropy for every ordinary recipe and shift
every later random outcome; and eligibility must not apply either, since
implicit unlocking is demand-derived, so an ordinary recipe's output can be
producible while nothing yet calls for it -- testing it would stop the building
producing rather than gate a drop. Past the early-out a group is eligible only
when all of its items are unlocked, being produced whole.

Threat follows the recipe's shape rather than the building, and the per-unit
value now divides by the group's amount as well as its odds. That moves no
number today: every item resolved through this path has amount 1, which is why
the threat expectations are untouched.

Config keeps `outputs = [...]` as the single-group form, so only the two
reprocessing recipes change shape. The recipe summary gains "/" between groups
and keeps "+" within one, which also fixes the plant reading as though a cycle
produced all of its items at once.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x

docs/balancing/rules.md

@@ -230,8 +230,8 @@ supporting different fleet doctrines feel structurally different to build.
   **smelting** (same basic materials as ore — the safe, boring option) and
   **reprocessing** (probabilistic higher intermediates, including the
   late-game input — the gamble that eventually becomes mandatory).
-- The reprocessing output pool renormalizes over implicitly unlocked items
-  (REQ-LOCK-OUTPUT-POOL), so its output quality improves
+- The reprocessing output pool renormalizes over the output groups whose items
+  are implicitly unlocked (REQ-LOCK-OUTPUT-POOL), so its output quality improves
   automatically as the run progresses. **Rule:** weights are authored for
   the *fully unlocked* pool state; early-game behavior falls out of
   renormalization for free and needs no separate staging.