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

src/lib/core/SchematicChoiceOption.h

@@ -21,6 +21,17 @@ struct GrantedSchematic
     std::string displayName;
 };
 
+// One recipe shown in an option's preview, together with the output groups the player
+// would be able to get out of it afterwards -- indices into the recipe's own
+// `outputGroups`, in config order (REQ-DEF-SCHEMATIC-DROP). The indices are what the
+// preview draws: which groups a recipe can yield is decided here, against the unlock
+// state as it would stand after the award, and not by the dialog against the current one.
+struct PreviewedRecipe
+{
+    std::string      recipeId;
+    std::vector<int> outputGroupIndices;
+};
+
 // One option presented to the player in the schematic choice dialog
 // (REQ-DEF-SCHEMATIC-DROP). Built by the simulation when enemy stations are
 // destroyed; the UI reads these to populate the dialog. A non-artifact option
@@ -40,8 +51,16 @@ struct SchematicChoiceOption
     // (empty for the artifact option).
     std::vector<GrantedSchematic> grantedItems;
 
-    // Ids of miner/assembler recipes that would newly become implicitly
-    // unlocked (REQ-LOCK-IMPLICIT) if this option is selected. Sorted
-    // alphabetically by display name; empty if none.
-    std::vector<std::string> newlyUnlockedRecipeIds;
+    // What this option would add to the player's production options
+    // (REQ-DEF-SCHEMATIC-DROP), each sorted alphabetically by display name. The unit is
+    // usability rather than unlocking: a recipe is of no use while the building that
+    // runs it cannot be placed, so unlocking that building is as much a gain as
+    // unlocking the recipe was.
+    //
+    // Recipes the player could not use at all before and could after.
+    std::vector<PreviewedRecipe> newlyUsableRecipes;
+    // Recipes they could already use that would gain at least one further output group
+    // -- a plant that starts yielding voidsteel is a real gain, and one a list of recipe
+    // names alone cannot express.
+    std::vector<PreviewedRecipe> upgradedRecipes;
 };