MM3 stretch-bend: OpenMM/Tinker implementation + wildcard atom type matching

[ericchansen]

Background

The MM3 .fld parser already reads stretch-bend cross-term entries
(ptype="sb") at q2mm/io/mm3.py:498-525, but those terms are never
mapped into ForceField for any of the three MM backends:

• q2mm/backends/mm/openmm.py — zero stretch_bend references
• q2mm/backends/mm/tinker.py — zero stretch_bend references
• q2mm/backends/mm/jax_engine.py — zero stretch_bend references

So all three backends ignore stretch-bend terms equally. This is a
symmetric gap, not a parity bug — JAX matches OpenMM on every system
in the test suite and the published-FF validation page.

Why we're not fixing it now

It would touch:

1. The MM3 parser → ForceField model (new StretchBendParam)
2. OpenMM CustomCompoundBondForce (or equivalent) wiring
3. Tinker engine wiring (already handled internally by Tinker — would
   need to verify)
4. JAX _compile_energy_fn + a new _stretch_bend_energy helper
5. Three-way parity tests on a system that actually has measurable S-B
   contributions (none of our current benchmarks do)

That work isn't justified until a benchmark or user workflow
demonstrably depends on it.

Reopen when

A user reports a parameterization where the QM Hessian off-diagonal
bond/angle coupling is too large to absorb into the bond and angle
force constants alone, AND a published MM3 force field with non-zero
S-B parameters needs to be reproduced.

Source

Wrap-up PR (feat/wrap-up-analytical) — see
plan.md Phase 6 deferral rationale.

Refs #176.

[ericchansen]

Status update after PR #267

The JAX engine now fully implements stretch-bend cross terms (PR #267):

Done

• StretchBendParam dataclass in forcefield.py with elements, force_constant, env_id, ff_row, canonical key
• ForceField.match_stretch_bend() with ff_row → env_id → element fallback chain
• _mm3_stretch_bend_energy() in JAX engine: E = Σ k_sb · [(r_ij−r0) + (r_jk−r0)] · (θ−θ0) with near-linear damping
• Runtime r₀/θ₀ from param vector (not frozen at build time) — correct gradients during optimization
• mm3_sb_k_to_canonical() using Allinger's 2.51118 × (180/π) = 143.88
• canonical_to_mm3_sb_k() inverse + save round-trip in save_mm3_fld()
• SB params in get_param_vector(), get_bounds(), get_step_sizes(), get_param_type_labels()
• compute_param_offsets() updated with n_sb_types in all engines
• 4 SB numerical tests (analytical value, equilibrium=zero, differentiable, unit conversion)

Not done

• OpenMM: NotImplementedError raised when forcefield.stretch_bends is non-empty
• Tinker: no changes (Tinker handles SB internally via its own MM3 implementation)
• JAX-MD: NotImplementedError raised when forcefield.stretch_bends is non-empty
• Wildcard atom type 00: MM3 standard-body SB params use 00 for "any heavy atom" — _extract_element('00') returns '00' which never matches. 3 of 6 Rh-enamide SB params are affected.

Issue title should be updated

The title says "not implemented in any engine" — JAX now has it. Suggest renaming to "MM3 stretch-bend: OpenMM/Tinker implementation + wildcard atom type matching".