preview what an award adds, not which recipes it unlocks

The unlock dialog drew each previewed recipe with every output group its config
lists. Filtering those against the current unlock state would have been worse
than not filtering: these recipes are previewed precisely because the award
changes what they may yield, so the current state would have emptied the very
lines the preview exists to show.

So the preview stops being a recipe-id diff and becomes a usability diff.
A recipe is usable when the player may run it, may place the building that runs
it, and it has a group it could be handed; the option carries the difference
between usable-now and usable-after, per recipe, down to which groups. The
dialog then draws what it was handed instead of re-deriving eligibility against
a state that is not the one being previewed.

Two consequences fall out of the finer diff, both wanted:

Unlocking a building is now a gain in its own right. A recipe unlocked long ago
but useless for want of a plant belongs to the award that finally makes it
usable, not to the one that unlocked it.

A recipe that gains a group is a gain a list of names cannot express -- a plant
that starts yielding voidsteel is the game's headline unlock. Those get their
own list under "Upgrades recipes:", because a recipe the player already runs,
listed as newly unlocked, reads as a bug. Each line is drawn whole, groups the
player already had included; the caption carries the difference.

toOutputGroups' unfiltered form has no callers left and is gone.

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

docs/requirements.md

@@ -380,9 +380,16 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
 
   Each option in the dialog displays the unlock group's display name — derived from its `id` (same display convention as building, module, and recipe ids) — and the list of items it would grant: its ship, module, building, and assembler-recipe ids (each shown with the same display convention as its respective selection dialog). The artifact option (if present) is displayed as a distinct entry with the name "Artifact".
 
-  Each option additionally displays a vertical list of recipe lines labeled "Unlocks recipes:", showing which recipes would newly become implicitly unlocked (REQ-LOCK-IMPLICIT) if this option were selected — every recipe, of whatever building, that is not currently implicitly unlocked but would become so after applying this option's effect. A Smelter or Reprocessing Plant recipe appears here exactly when the award makes something it can yield useful for the first time, which is as much a new production path as a miner recipe is. To compute this, all `materials` of the group's granted ship and module schematics are added to the base set per REQ-LOCK-IMPLICIT step 1a, and the output items of the group's granted assembler recipes are added per step 1b, before recomputation.
+  Each option additionally displays what selecting it would **add to what the player can produce**. The unit is *usability*, not unlocking: a recipe is usable when it is unlocked (REQ-LOCK-IMPLICIT), the building that runs it can be placed (REQ-LOCK-BUILDING), and it has at least one output group it could be handed (REQ-LOCK-OUTPUT-POOL) — a recipe the player cannot run is no gain, whichever of those three is missing. Usability is computed for the current state and for the state the award would bring about, and the difference is what the option displays. Computing the second: all `materials` of the group's granted ship and module schematics are added to the base set per REQ-LOCK-IMPLICIT step 1a, the output items of the group's granted assembler recipes per step 1b, and the group's granted buildings are treated as placeable, before recomputation.
 
-  Each recipe is shown as a **recipe line** of the same two-row card the item production tooltip uses (REQ-UI-ITEM-TOOLTIP): the icon of the building that runs it (REQ-UI-BUILD-ICON) and the recipe's name — by its `id`, using the same display convention as the assembler recipe-selection dialog — on the first row, and the recipe drawn as the recipe summary draws it (REQ-UI-RECIPE-SUMMARY) on the second. The lines are sorted alphabetically by recipe name. The line says everything there is to say about the recipe, so nothing in this list carries a tooltip describing it, as in the selection dialog (REQ-UI-SELECT-OPTIONS); the items the line names do explain themselves, on hover or click: the card is not itself clicked, the option being taken with the button beneath it (REQ-UI-ITEM-VALUE-TOOLTIP). If no recipes would be newly unlocked, the list shows "None".
+  The difference is shown as **two vertical lists of recipe lines**, because an award adds production in two different ways and a player shown the second as if it were the first reads it as a mistake — a recipe they already run, listed as new:
+
+  - **"Unlocks recipes:"** — recipes not usable before and usable after. This covers all three ways that can happen: the recipe unlocked, its building became placeable, or its first output group became yieldable. A recipe unlocked long ago but never usable belongs to whichever later award finally makes it usable, not to the one that unlocked it. If there are none, the list shows "None".
+  - **"Upgrades recipes:"** — recipes already usable that gain at least one further output group. A Reprocessing Plant that starts yielding voidsteel is a real gain and one a list of recipe names alone cannot express. This list is omitted entirely when empty, rather than showing "None": having nothing to upgrade is the ordinary case, and a second "None" would only be noise.
+
+  Each line states the recipe **whole**, including the groups it could already yield — the caption is what says whether the recipe is new to the player or newly better, so the line does not have to. Groups the recipe still could not be handed after the award are left out of both lists, exactly as they are wherever a recipe is drawn (REQ-UI-RECIPE-SUMMARY); the difference here is only that eligibility is judged against the state the award would bring about rather than the one the player is still in.
+
+  Each recipe is shown as a **recipe line** of the same two-row card the item production tooltip uses (REQ-UI-ITEM-TOOLTIP): the icon of the building that runs it (REQ-UI-BUILD-ICON) and the recipe's name — by its `id`, using the same display convention as the assembler recipe-selection dialog — on the first row, and the recipe drawn as the recipe summary draws it (REQ-UI-RECIPE-SUMMARY) on the second. The lines are sorted alphabetically by recipe name, within each list. The line says everything there is to say about the recipe, so nothing in either list carries a tooltip describing it, as in the selection dialog (REQ-UI-SELECT-OPTIONS); the items the line names do explain themselves, on hover or click: the card is not itself clicked, the option being taken with the button beneath it (REQ-UI-ITEM-VALUE-TOOLTIP).
 
   **The dialog cannot be dismissed.** Clicking an option is the only thing that closes it: it has no close button, no Cancel, neither Escape nor Q dismisses it, and a click outside it does nothing (REQ-UI-DIALOG-DISMISS). The drop is a reward the player has earned by destroying the station set, and every way out of the dialog would have to either forfeit it or pick an option the player did not — so there is no way out but choosing. The dialog is modal and the game is paused meanwhile, so nothing is waiting on the decision.