Several 2.x device wrappers have update()/operator() paths that never compile or silently apply stale state

Description

A cluster of 2.x-era device-level wrappers has broken or silently stale update() / convenience operator() paths. None of these are reachable from in-tree callers (the profiler and examples use initialize/run), so they only surface when a user calls them directly.

Never compiles

1. gemm/device/gemm_array.h:404-408 - both specializations' update() call

   threadblock_swizzle.get_tiled_shape(args.problem_size, args.batch_count, {kM, kN, kK});
   

   i.e. (GemmCoord, int, GemmCoord). The swizzle only offers (GemmCoord, GemmCoord, int) (plus conv variants); there is no matching overload. (initialize() uses the correct order.)

2. gemm/device/gemm_splitk_parallel.h:620 - the ColumnMajor-output specialization's operator()(args, workspace, stream) calls initialize(args, workspace, stream), but both specializations declare Status initialize(Arguments const&, void*). The RowMajor path calls the 2-arg form.

3. gemm/device/gemm_universal_with_broadcast.h:348, gemm_universal_streamk_with_broadcast.h, gemm/device/gemm_with_k_reduction.h:377, gemm/device/gemm_layernorm_mainloop_fusion.h:347 - all four forward update(to_underlying_arguments(args), workspace) through a chain that ends at GemmUniversalBase::update(Arguments const&) (gemm_universal_base.h:425, one parameter). The intermediate gemm_universal.h:404 forwards two arguments into it, so the chain cannot compile.

4. gemm/kernel/rank_2k_grouped.h:328 - Rank2KGrouped::Params::update does output_op = args.output_op; but the Arguments member is named epilogue (:205). Compile error if instantiated; note this update also drops lda/ldb/ldc/ldd/mode even if the name matched.

5. gemm/device/gemv_blockscaled.h:134-136 - update() calls params_.update(args), but the kernel's Params has no update member at all (unlike both kernel/gemv.h specializations).

Compiles but silently applies stale state

6. gemm/device/symm.h:301 / trmm.h:459 (and their second specializations) - initialize() builds Params from args.swapped_matrices() for SideMode::kRight, but update() passes raw args to params_.update(...). After an update on a right-side problem, the mainloop reads the symmetric operand with unswapped strides: wrong results or out-of-bounds access.

7. gemm/device/gemm_sparse_with_absmax.h:298-315 - update() refreshes ref_A/B/C/D/E and output_op but not ref_Aux/ptr_Vector/ldr, which exist in the kernel Params (sparse_gemm_with_absmax.h:109-110) and are refreshed by the sibling non-sparse absmax wrappers' updates. Post-update runs keep writing the absolute-maximum output to stale pointers.

8. gemm/device/gemm_splitk_parallel.h:315-331 - update() refreshes operand pointers only; args.epilogue (alpha/beta consumed by the reduction launch) and any geometry changes are discarded while kSuccess is returned.

Suggested fix

For each wrapper either implement update() consistently with initialize() (same argument transforms, same fields refreshed) or delete the dead entry points so users get a clear "not implemented" instead of a compile error or stale success.

Start by comparing initialize() and update() in the listed device wrappers, especially gemm/device/gemm_array.h, gemm/device/gemm_splitk_parallel.h, gemm/device/gemm_universal_with_broadcast.h, symm.h, trmm.h, and gemm_sparse_with_absmax.h. Trace each path into the corresponding kernel Params and GemmUniversalBase::update, then verify every affected wrapper either compiles and refreshes equivalent state or clearly rejects unsupported updates.