extract elliptic-cone middle-zone force/cost into a helper

[etaoxing]

Pull the middle-zone force and cost math out of _eval_constraint into a reusable _eval_elliptic_middle helper. No behavior change; this just makes the elliptic-cone force available as a single source of truth instead of inlined in the constraint eval.

---

Performance was measured on an NVIDIA RTX PRO 5000 Blackwell with 8,192 worlds and 1,000 steps. Values are means over 10 interleaved runs after unmeasured warmups, comparing origin/main (d28130a) with this PR (a74cf9d). The only model override is opt.cone=elliptic, since both models default to pyramidal cones and would never reach the changed code; the solver stays on its default (Newton) and the Jacobian stays on auto, which resolves to dense for Humanoid (nv=27) and sparse for G1 (nv=35). Contact and constraint limits come from the benchmark definitions in benchmarks/*/__init__.py. G1 uses the prerecorded shuffle_dance.npz trajectory; Humanoid uses its standard keyframe rollout. Every run converged all 8,192 worlds with unchanged solver iteration distributions.

Benchmark	origin/main	This PR	Difference
Humanoid, elliptic	3.093 s	3.093 s	-0.01%
G1 flat, elliptic, prerecorded	6.001 s	5.999 s	+0.02%

A positive difference means this PR is faster. Both are an order of magnitude below run-to-run variation, so this is parity rather than a change in either direction. That is the expected result: the middle-zone arithmetic is unchanged and Warp inlines the extracted wp.func, so the generated kernel is equivalent. The benchmarks are here to show the refactor costs nothing, not to claim a speedup.

[etaoxing]

for #1535

[thowell]

@etaoxing lets run the humanoid benchmark before and after the changes to confirm that there are no regressions. thanks!

[etaoxing]

@thowell updated above with benchmark timings!