Dakota issue 9: make Dakota stdout parsing version-tolerant

[JavierGOrdonnez]

Parent epic: #12
Source: ITISFoundation/mmux_python#3

Current status: Partial. Method-specific regex parsers and regression tests exist, but parsing remains format- and version-dependent.

Acceptance criteria:

• Define supported Dakota output versions and parser compatibility behavior.
• Parse stable structured signals where possible and fail with actionable diagnostics otherwise.
• Add fixed-output fixtures for supported methods and versions.

[JavierGOrdonnez]

Assessment 2026-08-19 — partially addressed (status:in-progress)

Done. Working parsers exist for the methods in use (src/itis_sumo/data/funs_data_processing.py, src/itis_sumo/evaluate/funs_evaluate.py), and malformed rows are healed-or-dropped with a trace rather than silently wiped (SPEC V7as).

Missing. Nothing defends against the drift the source issue actually describes — format varying per Dakota method and per Dakota version:

• There are no snapshot/golden tests pinning Dakota stdout for a fixed config + data, so a version bump changes parser behaviour silently. This exact safeguard was agreed at the 2025-08-12 meeting and never built.
• Only one engine version is exercised (itis-dakota==1.5.9, Dakota 6.20), so cross-version tolerance is untested by construction.

Next step. Add stdout snapshot tests per method before the engine ladder in SPEC T16mo moves off 6.20 — otherwise the bump is the thing that discovers the parser breakage.