ForceFreeStates - BUGFIX! - Snap the periodic theta endpoint before integrating GGJ geometry

[adrianaghiozzi]

Release note

• Audience: developers
• Numerical impact: none (harness @ 987e63f, diiid_n1: 47/47 quantities bit-identical, develop vs. local)
• Migration: none

resist_geometry (ResistEval.jl) and resist_eval (Resist.jl) build the GGJ
theta-integrand independently at each theta node, including both periodic
endpoints, then integrate with cubic_interp(...; bc=PeriodicBC()). The two
endpoint evaluations can differ by machine epsilon, which a stricter
PeriodicBC(endpoint=:inclusive) validator now rejects outright, aborting
force-free-state prep on some equilibria (mine hit it via a DIII-D case
driven from TokToxStability).

What

Snap ff[end, :] .= ff[1, :] right before each cubic_interp call, in both
ForceFreeStates/Surfaces/ResistEval.jl and the sibling
ForceFreeStates/Surfaces/Resist.jl (same GGJ-integrand pattern, same latent
bug -- not yet observed in the wild but a spot check shows it will trip the
same way on the right input).

This mirrors the fix already in Equilibrium.jl's GS-residual integrator:

# Snap the repeated endpoint exactly equal to the start
fs_matrix[end, :] .= fs_matrix[1, :]
itp = cubic_interp(equil.rzphi_ys, Series(fs_matrix); bc=PeriodicBC())

Context

• Closes the remaining gap from PeriodicBC endpoint validator triggered by machine-epsilon mismatches; use targeted endpoint closure instead of blanket check=false #240, whose "proper fix" pattern (explicit
  endpoint closure at the data-construction site, not check=false) was
  applied everywhere in PR FastInterpolations bump and fix #243 except ForceFreeStates/Surfaces/.
• Unrelated to the still-open KineticForces parallel-velocity-spline
  periodicity issue (KineticForces: preserve periodic vpar spline and enumerate bounce roots exactly #341, KineticForces - BUGFIX! - Fit the parallel-velocity spline periodically #390) -- that's a different spline (tspl/vpar
  in Torque.jl/BounceAveraging.jl), not the GGJ geometry integrand here.

Regression report

regress --cases diiid_n1 --refs develop,local

Regression Report: diiid_n1
=================================================================================================
Ref 1: develop  @ 987e63f3b (2026-08-28)
Ref 2: local    @ local     (2026-09-01)
-------------------------------------------------------------------------------------------------
Summary: 47 unchanged

Also ran the existing test/runtests_resist_eval.jl suite: 63/63 passed.

Notes for reviewers

No behavior change expected or observed -- this only prevents a false-positive
validator abort on machine-epsilon endpoint drift, matching the fix pattern
already established for #240.

[github-actions]

This pull request is missing an assignee.

If you are not ready to name them, mark this pull request as a draft.
docs/development/contributors.md suggests lead developers to ask.
Merging is not blocked here, but no pull request may be merged without human review.

[matt-pharr]

@adrianaghiozzi Looks reasonable, but the comments are not really necessary, are they? The git blame will still point to this pr with reasoning. At most if you really think this needs comments, one curt line suffices

[adrianaghiozzi]

@matt-pharr Verbose Claude comments strike again lol I just shortened them in cefa010