Unify the e-ph loop argument lists, drop the batched dummy padding, and name LoopContext construction

[jaemolihm]

Motivation

Three TODO.md "## GPU" items, all readability debt in the two hottest loops in the package. PR #13
split use_gpu into backend + batched but left the loops themselves as they were:

• the per-point and batched loops take divergent argument lists, so a reader comparing them cannot
  tell shared data from path-specific data;
• both batched loops pad a partial final batch with duplicated valid data so the batched kernels
  run on dense nk_batch_max-sized arrays, and the two sites neutralize the tail differently
  (outer-k trims to views, outer-q relied on a wtk = 0 sentinel) — flagged as a semantic trap in the
  2026-07-17 architecture review;
• LoopContext is built from positional constructors disambiguated only by whether argument 3 is an
  Integer outer index or a UnitRange batch.

Pure refactor: no physics, no intended numerical change. bte_scattering_increments is untouched
and no ext/ file changes.

Change

A — one positional list per loop pair. The per-point and batched loops now take identical
positional arguments, with path-specific data as keywords: per-point
(epstates, ep_ekpRs, epmat, ep_ekpR_obj, dyn_threads, epmat_R, epobj_ekpR_R, ep_ekpR_Rs),
batched (epmat_dev,). backend becomes a shared positional in both loops of all three drivers,
removing three hardcoded backend = CPUBackend() constants whose correctness a reader previously had
to re-derive from the entry validation. The argument-convention comment is now stated once
(canonical block above _loop_eph_over_k_and_kq) with one-line pointers elsewhere — each positional
list appears exactly once, which is what let a stale "backend is positional #9" claim drift into a
file where it is #7.

B — the dummy padding is gone from both sites. Partial tails are no longer computed at all: every
consumer takes a width-nk_batch trailing-prefix view. This deletes the outer-k tail fill and its
fill!(P_mk, 1), and the outer-q tail fill including the wtk = 0 sentinel — the payload width is
now the only guarantee, identically at both sites.

One driver-side change was needed: get_eph_Rq_to_kq_batched! asserted its workspace sizes with
equality, so a shared max-width workspace threw on a partial batch. Its sibling
get_eph_kR_to_kq_batched! already solved this (>= assertions plus internal
view(ws.g, :, 1:nq)), so this mirrors that — making the two siblings consistent rather than adding a
convention. No consumer needed a dense fallback and no driver signature was widened:
view(::CuArray, :, :, 1:n) is a derived CuArray, not a SubArray, and reshaping keeps that.

C — named LoopContext construction. LoopContext(backend, ::BatchedMode; outer_index, batch, n_batch_max) is keyword-only, and the per-k context is visibly derived via with_outer_index. All
six driver sites use named forms; the field-wise constructor stays available for the unit tests that
deliberately probe field combinations production never builds. n_batch_max's dual meaning (outer-k
batch width in one loop, inner-k in the other) is now documented, with the note that a
TiledDeviceOutput-style consumer is outer-k-only.

Docs moved with the code: the EPDataKBatched padding paragraph, and README_GPU.md's Deferred
"View-instead-of-fill for the outer-q staging buffers … benchmark it on its own before adopting" entry
is deleted rather than left contradicting the code.

Test

suite	result
runtests.jl, no CUDA	22519 / 22519 (3m58s)
runtests.jl, with CUDA (A100)	22636 / 22636 (2m19s)
test_gpu.jl on A100-80GB	all testsets, incl. new GPU partial k-batch 5/5
test_calculator_contract.jl	27/27, incl. new LoopContext named construction 7/7
boltzmann/test_gpu_boltzmann_calculator.jl	8/8 incl. the GPU arm
MigdalEliashberg.jl/test/runtests.jl	41/41, both GPU testsets

Every reference deviation is bit-identical to the 1901141 baseline — outer-k CPU+batched vs
CPU+per-point 8.027231620421635e-16, outer-q 3.0427801012277363e-16, outer-q CPU-vs-GPU
8.114080269940629e-16, BTE Sᵢ 1.3380159109184602e-15, Sₒ 6.11269303778053e-16. The bit-exact
assertions still hold, including ME's cgb.g2 == cgf.g2 at nk = 173 with nk_outer_batch_max = 4
(44 batches, last width 1 — the strongest partial-tail GPU arm in the stack).

Bit-neutrality is not a guarantee on the GPU, and the record says so. Narrowing a batch is
bit-neutral on the CPU by construction (OpenBLAS's K-blocking order is N-independent; the generic
batched_gemm!/eigen_batched methods are per-slice mul!/syev!), and eigen_batched is safe on
both paths because the deleted padding was a duplicate of column nk_batch, leaving the set of
distinct matrices — and any heevjBatched! sweep count — unchanged. But cuBLAS selects its algorithm
from N non-monotonically at small M, so N-narrowing is reduction-order-relevant: at the outer-q
shape (M=48, K=700), N 64→32 differs by 3.34e-15, 32→16 by 3.95e-15, 20→6 by 3.97e-15. The
widths this PR's tests actually hit (10→4, and every outer-k RR→kR shape) come back exactly 0.0,
which is why the measured deviations are unchanged — but do not add a bit-exact GPU regression across
a partial tail on the strength of it.

Coverage added by PR #13 is preserved: nk = 66 at nk_outer_batch_max = 20 still gives 4 tiles
(20/20/20/6), so a nonzero Sᵢ tile_offset and a partial tail both still occur, with the
precondition guard intact. with_outer_index(ctx_batch, ik) reproduces the old 5-field context
exactly. A new unit test pins the >=/prefix-view workspace change directly (bitwise equal to the
independent ws === nothing fresh-allocation branch at nmodes = 4, with a permutation control
proving the arm non-vacuous).