generator: discover items from XML when base.ini has no entry

[denis-coach]

Reverse the enhancement generator's skip logic: instead of silently discarding DataForge XML entities whose loc key is absent from base.ini, synthesize a description from XML attributes and emit them into the enhancement INI files. These entries flow through the existing "enhancements" source injection and get status "New" in the table.

Changes:

• Add _synthesize_description() helper that builds rich descriptions from XML (career/role/crew/length for ships, item type for components, tracking type for missiles, filename stem as fallback)
• scan_entity_dir() and scan_spaceships() no longer skip missing keys; they synthesize descriptions and emit discovered items
• Mission title/desc assembly synthesizes from contract debug names when loc keys are missing from base.ini
• _component_name_tag() falls back to XML ItemComponentParams for size/type when the description text lacks Size:/Grade:/Class: lines
• Add shield/cooler/powerplant/qdrive/radar to _ITEM_TYPE_ABBREV so the tagger's fallback path works for all component types
• Name tag generation synthesizes name values from XML file stems for discovered items whose name key is not in loc
• append_enhancements() guards against None existing_value

Covers all category scanners: ships, components, weapons, missiles, FPS weapons, and missions. Crafting blueprints deferred (different discovery pattern).

17 new tests in test_discovered_items.py. Full suite: 578 passed, 4 pre-existing failures in test_pak_extraction.py.

[Osiris-DevWorks]

Walking through this PR. Leaving one note on the parser change. More may follow as I review the rest.

[Osiris-DevWorks]

New is being set in two places now — line 188 (if key not in base_merged) and this new branch.

src/parser/CLAUDE.md names _determine_status_from_source as the single source of truth for status mapping but it never actually returns 'New' since the signature can't tell whether the key is in stock base — the call site has to know.

Could we consolidate? Something like _determine_status_from_source(source_name, base_source, *, key_in_base: bool) with both New branches moved inside. Line 188 already split it before this PR so this isn't new debt, just a natural moment to clean up if you want.

[Osiris-DevWorks]

"Include new lines" is ambiguous. Let's use something a bit more descriptive like:

• "Include discovered items"
• "Include 'New' status entries"
• "Apply XML-discovered items"

[Osiris-DevWorks]

This literal map is rebuilt on every call to _component_name_tag and duplicates the CamelCase-splitting logic that attach_class_name already does:

attach_class_name = re.sub(r"([a-z])([A-Z])", r"\1 \2", subtype)

Same approach would work here:

if raw_type:
    xml_item_type = re.sub(r"([a-z])([A-Z])", r"\1 \2", raw_type)

That removes the literal map, deduplicates the CamelCase split, and makes the path generic — any new XML itemType would work without an entry being added.

If the explicit map is intentional as a controlled allowlist (only let these five types through the fallback), worth a comment saying so. Otherwise the regex is cleaner. Minor.

[Osiris-DevWorks]

This test has no assertion — the comment says "no direct way to check the counter (it's local)" and then just runs the function. As-is it passes regardless of whether discovery actually works.

Two ways out:

1. Delete the test (it doesn't verify anything the other tests don't already cover).
2. Rewrite to assert on the observable output:

result = gen_module.scan_entity_dir(
    tmp_path, dummy_enhancement_fn, loc=loc, capture_all=False,
)
assert "item_DescSHLD_A" in result  # discovered
assert "item_DescSHLD_B" in result  # in loc

That checks the function emits both even when the local counter itself is unreachable. Major.

[Osiris-DevWorks]

This test imports load_source_files but never calls it. The assertions only check that the two INIs were parsed — they don't exercise the new branch in ini_parser.py:196 (the if source == 'enhancements' and key not in base_sources...: status = 'New' path), which is the actual change this PR makes to the parser.

To verify the New-status classification, something like:

entries = load_source_files(
    sources_dict={"global": base, "enhancements": enhancement},
    hierarchy=["global", "enhancements"],
    user_overrides=None,
)
discovered_b = next(e for e in entries if e.key == "item_DescSHLD_B")
assert discovered_b.status == "New"

existing_a = next(e for e in entries if e.key == "item_DescSHLD_A")
assert existing_a.status == "Enhanced"  # in base AND enhancements → Enhanced, not New

As-is, the parser change has no test coverage exercising the new branch. Major.