Tracking: follow-up refactors for the reacting immersed-boundary surface chemistry (#1821)

[sbryngelson]

Tracking issue for the #1821 follow-ups, so the ordering is written down somewhere.

#1821 landed heterogeneous immersed-boundary surface chemistry as a single 2733-line change. It is reviewed and working, and splitting it retroactively would be churn — but the pieces inside it have different owners, different test strategies, and in one case a different repository.

Where the lines are

piece	~lines	belongs
surface Fortran codegen (input.py)	438	pyrometheus (#1891)
surface Newton solver (m_ibm.fpp)	400	its own module (#1892)
IB ghost-state coupling	70	m_ibm.fpp — correct as is
example + mechanisms + plot	1050	examples/ — correct as is
goldens	525	generated
params / checker / MPI plumbing	250	correct as is

Ordering

1. Move the surface-chemistry Fortran codegen upstream into pyrometheus #1891 — codegen to pyrometheus. First: it deletes the most MFC code, and it is the only piece with an external review cycle. Everything else is unaffected by it.
2. Extract the surface-chemistry solver out of m_ibm.fpp into its own module #1892 — extract the solver module. Pure move plus unit tests; goldens must not shift.
3. Nothing else. The remaining ~1400 lines are an example, its mechanisms, generated goldens, and ordinary parameter plumbing. Those are the right size and in the right place — this is not an argument that Add heterogeneous reacting surface boundary conditions #1821 should have been four PRs.

Why bother

The two extractions are what make the feature independently testable. Codecov reports 56.97% patch coverage on #1821 with 55 uncovered lines in m_ibm.fpp; the solver and the codegen are precisely the parts currently reachable only through a full 2-D reacting simulation compared against a golden. Both have already produced bugs that unit tests would have caught cheaply (a sticking-coefficient rate emitted as plain Arrhenius; a sum-constraint closure landing on a trace radical).

No action needed on #1821 itself.

[sbryngelson]

Status on the upstream item.

#1891 — codegen to pyrometheus. Open as pyrometheus/pyrometheus#118: generate_surface on all three backends, emitting a surface module that refers to the gas one, which is the shape MFC already consumes. Verified against Cantera to ≤1.5e-14 on two mechanisms, with the Fortran and C++ figures from compiled binaries. Handles the two forms the hand-written generator gets wrong or rejects (sticking coefficients, coverage dependence), so the MFC-side swap removes ~400 lines and lifts restrictions at the same time.

A second bug fell out of it, unrelated to surfaces: generating from a mechanism with no reactions produced code that raised IndexError when called, not merely unused locals. Filed as pyrometheus/pyrometheus#119, fixed in pyrometheus/pyrometheus#120.

#1892 — extract the solver module. Not started. It rewrites m_ibm.fpp, which #1821 is still changing, so it wants #1821 merged first or the conflict is guaranteed.

Ordering unchanged: #118 lands upstream, then #1891 here, then #1892. Nothing in this tracker is blocked on anything in MFC except #1821 merging.