[BUG] Dead legacy `RocketConfig`/`Any` CLI code across modules (su2, openvsp, gmsh) — gmsh.py does not even import

[aligatoralex]

Summary

While migrating module setup() methods to the BaseVehicleConfig contract (#28), several modules were found to still contain dead, broken legacy code left over from an old RocketConfig → generic-schema refactor. The pattern is a botched find/replace where a former config class was globally replaced with typing.Any, producing code like:

from typing import Any
...
config = Any.from_yaml(config_path)      # Any has no from_yaml
if not isinstance(config, Any):          # isinstance(x, Any) is a TypeError at runtime
    raise ValueError(...)

Affected locations

• YAADO_Core/modules/wind_tunnel/methods/su2/su2_config_template.py — module-level load_rocket_config(), run(), run_grid() reference the fictional Any-typed config; these entry points cannot be called today.
• YAADO_Core/modules/airframe/generator_methods/openvsp.py — load_rocket_config/build_vspscript/build_manifest/write_openvsp_export/main still use isinstance(config, Any) / vehicle_config: Any. Additionally main() calls analysis.setup(config, output_dir=...), which no longer matches the new setup(vehicle, operating_state) signature after [FEATURE] Standardize all modules' methods to use vehicle object #28.
• YAADO_Core/modules/airframe/slicer_methods/gmsh.py — fails to parse at all: a pre-existing IndentationError (~line 300, a stray indented from pydantic import ValidationError inside cross_check_against_vehicle_config), plus the same isinstance(config, Any) breakage.

These sit on standalone script/CLI paths, which is why the test suite (which imports the solver classes, not these functions) stays green and never surfaces them.

Why it matters

These are the same "parse a file from disk" anti-pattern #28 targets, but on the CLI side. They are currently non-functional, so any user following a module's python -m ... entry point hits an immediate crash.

Proposed fix

• Delete or rewrite the dead load_rocket_config/run/CLI helpers to load a real BaseVehicleConfig.from_yaml(...) and call the new setup(vehicle, operating_state) contract (mirroring what flight_dynamics/point_mass_3dof.py already does after [FEATURE] Standardize all modules' methods to use vehicle object #28).
• Fix the gmsh.py IndentationError so the module imports.
• Add at least a smoke import test per module so this class of breakage is caught by CI.

Discovery context

Found by the delegated subagents during the #28 standardization work (modules: wind_tunnel, airframe). Left untouched there per that PR's minimal scope.

[aligatoralex]

Additional finding (surfaced while writing RFC 0005 / CFD solver strategy, docs/rfcs/0005-cfd-solver-strategy.md, PR #47) that belongs in this issue's scope but wasn't added here yet:

YAADO_Core/modules/wind_tunnel/methods/su2/su2_config_template.py's module docstring says "none of those are installed in this environment (see docs/AGENT_CONTEXT.md Section 3)" — docs/AGENT_CONTEXT.md does not exist anywhere in the repo (verified directly: no docs/ directory at all on main before this session's doc PRs). Same module also still carries a stale header (# YAADO | analyses.cfd.su2_config_template | v0.3.0 — the pre-move path) and vehicle-specific "ramjet rocket" language sitting next to the newer generic "Generic Vehicle" wording in the same docstring paragraph.

Proposed fix (folded into this issue's existing scope, not a new item): when fixing the su2_config_template.py dead Any-typed config read already tracked here, also (a) update the module header path, (b) remove or replace the docs/AGENT_CONTEXT.md reference, (c) de-RamP-ify the docstring language — same cleanup pass, same file, same PR.

---

Generated by Claude Code

[Arseni10Lk]

This issue is fully covered by #29

None of the modules should load a config file themselves. They should simply use the object produced by vehicle_factory. If they use this object, there won't be any issues with loading YAML whatsoever, because YAML does not belong there.