perf: measure and bound GPU path-buffer memory in CV

[TheHiddenObserver]

Summary

Follow-up performance hardening identified during the final independent review of PR #116.

PR #116 correctly keeps LogisticRegressionCV candidate coefficient/intercept paths backend-native through validation scoring, eliminating repeated GPU→CPU→GPU parameter round-trips and preserving the active mixed-precision dtype. The tradeoff is that a path of roughly n_candidates × n_folds × n_features remains resident on the GPU until scoring, with additional temporary storage during stacking.

No production regression is currently demonstrated: the physical Tesla P100 validation passed across NumPy/CuPy/Torch, and the repaired Torch path was numerically aligned with CPU. The canonical artifact currently records peak_memory_bytes = null, so the memory tradeoff has not been quantified directly.

Proposed scope

• Add reliable peak-GPU-memory measurement for representative CuPy and Torch CV benchmarks.
• Characterize memory scaling versus candidate count, folds, and feature dimension.
• Determine whether the current list+backend.stack() construction materially increases peak memory.
• If warranted, preallocate backend-native path buffers or stream candidate/fold scoring without reintroducing host round-trips or changing statistical semantics.
• Preserve strict device/no-fallback behavior and three-backend parity.

Acceptance

• Benchmark evidence reports peak GPU memory for representative CV workloads.
• Any optimization is covered by numerical/selection parity tests on NumPy/CuPy/Torch.
• Large-grid/high-dimensional behavior has a documented memory bound or scaling characterization.

Related: PR #116. This is LOW-severity performance hardening and does not block PR #116.