Reject zero-thickness superconducting TF at input validation

[dallonby]

Closes #4534

Overview

Adds a check_process validation so that the silent zero-thickness-TF failure mode described in the issue becomes an immediate, actionable input error instead of an unexplained downstream solver failure.

Changes

• process/core/init.py: after the existing ixc 13/140 mutual-exclusion check, raise ProcessValidationError when i_tf_sup is superconducting, neither ixc 13 nor ixc 140 is active, and dr_tf_inboard <= 0. The message tells the user the three ways to fix their file. Stellarators (istell != 0, which calculate dr_tf_inboard during the model run) and IFE are excluded.
• New tests/unit/core/test_init.py: five tests — the rejected configuration, plus accepted configurations for explicit thickness, ixc 140 active, resistive TF, and stellarator.
• tests/unit/core/test_input.py (test-suite change, per CONTRIBUTING): the parser tests run init_process on minimal input snippets (e.g. just epsvmc = 1.0) and relied on config validation never examining the TF geometry; their shared fixture scaffold now sets a valid dr_tf_inboard so the parser tests keep testing parsing. No expected values change.

Behavioural impact

Valid configurations are unaffected (all seven shipped regression inputs pass: they each set ixc 13/140 or dr_tf_inboard, or are stellarator/IFE). The only newly-rejected configurations are ones that previously produced a machine with no inboard TF coil.

Verification

• Full unit suite: 847 passed / 4 skipped; integration suite: 21 passed / 1 skipped (Python 3.12, local).

Found during an independent audit of v3.4.2.

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 49.34%. Comparing base (c0ae5b2) to head (2fbe8a8).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4535      +/-   ##
==========================================
+ Coverage   49.32%   49.34%   +0.02%     
==========================================
  Files         150      150              
  Lines       29802    29804       +2     
==========================================
+ Hits        14700    14707       +7     
+ Misses      15102    15097       -5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[je-cook]

@ukaea/process-model-review this may adversely effect the optimiser as it is currently allowed to search invalid regions of space I think?

I suppose this is only checking init

[mkovari]

Obviously this needs to be fixed - maybe someone who has looked at this code more recently than me - @chris-ashe or someone?

[dallonby]

Init only. check_process is called from exactly one place, init_process (init.py:79), which SingleRun.__init__ runs once (main.py:339 then :432) before the Models objects are even built (main.py:340), so before Scan, SolverHandler or VMCON get anywhere near it. Scans don't re-init between points (scan.py just sets the swept variable), VaryRun spawns a fresh SingleRun per iteration, and dr_tf_inboard only gets written during model evaluation when ixc 140 is active (build.py:1684) or for stellarators, both of which the check excludes.

To be sure I wasn't reasoning my way past something, I instrumented it on the branch: 1 call to check_process vs 26 model evaluations (spherical_tokamak_eval, fsolve), 2029 (large_tokamak_nof, VMCON), 4286 (low_aspect_ratio_DEMO) and 16175 (a 3-point scan). One call every time, before the solve. So the optimiser's freedom to wander through invalid regions is untouched; the check only looks at inputs that are constant for the whole run.

Two things I should say explicitly though. It is a deliberate behaviour change for scaffold inputs that rely on the dr_tf_inboard = 0 default, which is why the test_input.py fixture needed a value. For what it's worth, on main those inputs currently either hit an uncaught ZeroDivisionError (tfcoil/base.py:424, circular case) or, with i_tf_case_geom = 1, report a "feasible solution" with a winding pack of -0.34 m and a negative turn count. And I only covered the superconducting case that was reported; a resistive TF with the same zero goes down the same build.py path, so it could be extended in a follow-up if you'd like.