[Status] SU2 integration is scaffold-only — writes .cfg but never meshes, solves, or parses results

[aligatoralex]

Summary

YAADO_Core/modules/wind_tunnel/methods/su2/su2_config_template.py only writes SU2 .cfg text files. Confirmed from the module itself:

• it never runs gmsh to produce the MESH_FILENAME= vehicle_airframe.su2 mesh every config references;
• it never invokes su2_CFD;
• there is no results parser — nothing reads an SU2 history_* / surface-CSV back into CL/CD/Cm.

Contrast: avl_wrapper.py does subprocess.run a real AVL binary and parse its output. So the AVL escalation path is real; the SU2 (LEVEL_2/LEVEL_3 CFD) path is a scaffold.

Why it matters

Several roadmap directions assume a working CFD pipeline:

• CFD surrogates (separate issue) accelerate an SU2 pipeline that does not run — that is why they are XL/deferred.
• Any LEVEL_2/LEVEL_3 fidelity result in FlightDeck's future optimization loop needs this.

Proposed work (a real end-to-end slice)

1. gmsh meshing from vehicle geometry → .su2 mesh (currently a TODO in every generated config; gmsh appears to be available in the env).
2. Invoke su2_CFD as a subprocess in a container/CI with SU2 installed (mirror avl_wrapper.py's pattern).
3. A results parser reading SU2 history/surface output into AnalysisResults.
4. At least one validated end-to-end run for a reference vehicle.

Discovery context

Surfaced by the MDO-directions research (PR #42, docs/research/mdo-directions-2026.md, cross-cutting finding #3 / direction R4).