Metal MPS POTRF allocates an MPSCommandBuffer per wide front per refactorization (~2.1 MB host allocation on lap2d_300) #137

Found while working on: T31 (PR #136)

What: ext/SparseDirectSolverMetalExt.jl, _offset_potrf_info!: every single-matrix Cholesky regime-C front at least 64 wide creates a new MPSCommandBuffer(global_queue(device())) in every (re)factorization, encodes the cached MPSMatrixDecompositionCholesky on the cached offset MPSMatrix, and commits it. The descriptors, kernels and status buffer are preallocated at allocate_numeric, but the wrapper objects are not: the PR author measured about 2.1 MB of host allocation per lap2d_300 refactorization on an M4 Max (18 wide fronts). AGENTS.md forbids allocation inside the numeric phase. Same command-buffer pattern would apply to any later MPS TRSM/GEMM binding. Expected: no host allocation per refactorization, or one command buffer per level/launch group.

Why it is out of scope: T31 review round 1 asked to record it rather than redesign the MPS path; it needs Metal hardware to measure. No task in TASKS.md owns Metal tuning after T31.

Suggested fix or plan change: encode all wide fronts of one level into one command buffer created per launch group, or reuse an encoder obtained from Metal.jl's KA command stream if Metal.jl exposes one; assert with a host allocation budget in a Metal-only test.