Support non-Py mod sets (and vanilla): gate Py-specific surfaces on data, not a mod check

[ApocDev]

PyOps was built for Pyanodons and Py stays first-class, but nothing in the core (solver, blocks, factory ledger, browse) is actually Py-specific — it's generic factory planning over whatever data dump you sync. We should let it run cleanly on any mod set, including vanilla.

Approach

Gate Py-specific UI on whether its data is present, not on detecting a named mod (pyalienlife etc.). Data-driven presence is more robust: it handles partial installs, mod renames, and other overhauls, and the empty state falls out for free.

Example: TURD is entirely data-driven (technologies.is_turd + turd_replacements, sourced from pyalienlife's pywiki_turd_page). With no Py, there are simply zero TURD techs.

Scope

• Step 1 (small, done separately): hide the TURD nav tab when the dataset has no TURD techs; soften the README wording away from "needs the Py mods".
• Audit every remaining Py assumption and gate/soften it: the AI assistant prompt (TURD strategy, byproduct/spoilage handling, additives lineage), any copy that assumes Py, additive classification, etc.
• Decide how far to go on the assistant — its planning heuristics are the most Py-shaped surface.
• Verify a vanilla data sync produces a usable planner with no dead-end tabs.

Keep all Py behavior intact — this is additive graceful-degradation, not a rewrite.