rank_2k_universal and symm_universal Arguments constructors discard batch_stride_B

Description

The Arguments constructors of two kernels discard their batch_stride_B parameter and store 0 instead:

// include/cutlass/gemm/kernel/rank_2k_universal.h:176
batch_stride_A(batch_stride_A), batch_stride_B(0),

// include/cutlass/gemm/kernel/symm_universal.h:173
batch_stride_A(batch_stride_A), batch_stride_B(0),

trmm_universal.h:158 stores its parameter (batch_stride_B(batch_stride_B)), which makes the intent clear; these are copy-paste typos. Confirmed by constructing Arguments for both kernels in a host program and printing the stored field: passing 200 stores 0.

Consequences:

1. Params construction copies args.batch_stride_B, so downstream code always sees stride 0.
2. Both kernels' transposed_problem() does std::swap(args.batch_stride_A, args.batch_stride_B) on an Arguments built by that constructor (rank_2k_universal.h:189), so after the swap the stored batch_stride_A becomes the dead 0 too: for the transposed path both batch strides are wrong, not just B's.

Additional observation while tracing this: neither kernel body ever reads params.batch_stride_A or params.batch_stride_B (unlike gemm_universal.h, which advances both pointers per batch), so batched operation through these kernels keeps A and B fixed across batches regardless of the arguments. The typo is provable on its own; the unused-stride observation may deserve separate attention.

Suggested fix

Store the parameter in both places:

batch_stride_A(batch_stride_A), batch_stride_B(batch_stride_B),

Start with the Arguments constructors at include/cutlass/gemm/kernel/rank_2k_universal.h:176 and include/cutlass/gemm/kernel/symm_universal.h:173, comparing them with trmm_universal.h:158. Reproduce the issue with the host program described in the report and verify that passing 200 preserves batch_stride_B, including through transposed_problem().