Function gemm_packed_a 

pub fn gemm_packed_a<T: GemmScalar>(
    alpha: T,
    packed: &PackedLhs<T>,
    b: MatRef<'_, T>,
    beta: T,
    c: MatMut<'_, T>,
    par: Parallelism,
)

C <- alpha*A*B + beta*C, consuming a PackedLhs (A prepacked once) instead of A itself, using the thread-local workspace pool. This skips the per-call LHS pack that gemm would run

The result reproduces plain gemm under the same config, except that 2 shapes may differ in the last ULP while staying correct. This can happen for a small product, where both m and n are at or below crate::tuning::small_mn_dim, or for a gemv-shaped product, where m == 1 or n == 1. As with gemm_packed_b, this path always drives the general driver through the transposed consume. Plain gemm instead reroutes those shapes to a dedicated kernel with a different accumulation order

Panics

Panics if the dimensions disagree (A.cols != B.rows, A.rows != C.rows, B.cols != C.cols), if B or C addresses outside its slice, or if C aliases itself or B. Also panics if C is not row-major-ish (|csc| <= |rsc|), because a column-major C would leave A in the genuine LHS role, which a prepacked A, laid out as the transposed RHS, cannot serve. Use plain gemm for that layout