perf(leiden): replace per-row GrB_Col_extract with CSR walk

[gkorland]

Summary

Addresses Dr. Davis's review feedback that the initial Leiden implementation "doesn't exploit much of GraphBLAS" and is therefore slow. The dominant cost was per-node GraphBLAS overhead inside the Phase 1 / Phase 2 hot loops; this PR removes it without changing algorithm semantics.

Changes

• CSR materialization per level. Once per outer aggregation level, materialize A_cur into portable CSR arrays (Ap, Aj, Ax) via a single GrB_Matrix_extractTuples_FP64 + counting-sort scatter. The Phase 1 / Phase 2 inner loops now walk Aj[Ap[i]..Ap[i+1]) directly instead of calling GrB_Col_extract + GrB_Vector_nvals + GrB_Vector_extractTuples_FP64 for every node × every inner iteration × both phases (the dominant cost).
• k_arr from CSR. Compute degree directly from CSR row sums; remove the per-level GrB_Matrix_reduce_Monoid + per-element GrB_Vector_extractElement_FP64 loop.
• GrB_Matrix_build_FP64 for S_mat. Single-call construction instead of n_cur GrB_Matrix_setElement_FP64 calls + implicit GrB_Matrix_wait. Existing scratch buffers (nbrs_j, dirty_list, nbrs_v) are reused for the build inputs.
• GrB_Vector_build_INT64 for output. Single-call construction instead of n GrB_Vector_setElement_INT64 calls (also fixed in the empty-graph fallback).
• CSR/tuple buffers grow on demand and are released through LG_FREE_WORK on every error path.

Algorithm semantics (node iteration order, tie-breaking with > vs >=, self-loop skipping, modularity formula, Leiden parent-community refinement constraint) are preserved.

Testing

test_leiden still passes:

====== karate.mtx ======
  Modularity Q = 0.418803  (K_ref <= 34)
[ OK ]
SUCCESS: All unit tests have passed.

Q ≈ 0.42 on Zachary's karate club matches published Louvain/Leiden benchmarks for that graph.

Memory / Performance Impact

• Per-level work in the local-move and refinement phases drops from O(n_cur · iters · GrB-call-overhead) to O(nnz · iters) with no GraphBLAS overhead in the hot loop.
• Additional memory: 6 arrays of size max(nnz) (Ap, Aj, Ax, I_tup, J_tup, X_tup) plus an n-sized cursor and an iota index array. Buffers grow on demand and are reused across levels.
• No new GraphBLAS feature dependencies (no GxB unpack/pack); uses only standard GrB_* API.

Related Issues

Follow-up to #401 (community: implement Leiden community detection).

[GomezGab]

From what I can tell, the algorithm doesn't exploit GraphBLAS for speed/parallelism on the most intensive parts. I don't yet understand Leiden enough to give advice as to how to effectively exploit GraphBLAS in these places.

[GomezGab]

As I understand it, we are starting to move away from implementing vanilla GraphBLAS methods and are generally okay returning GrB_NOT_IMPLEMENTED where Suitesparse is not available, and it would be excessively inconvenient to implement with the vanilla methods (ie. having to build the csr arrays by hand). @DrTimothyAldenDavis please confirm this.

[GomezGab]

Fall back should use GrB_unpack when possible. or simply refuse (GrB_NOT_IMPLEMENTED)

[DrTimothyAldenDavis]

We don't need vanilla methds. The entire function can just return GrB_NOT_IMPLEMENTED.

I would like to simplify LAGraph and remove all notion of the "vanilla" methods, and just explicitly rely on SuiteSparse GraphBLAS only. That's something for the LAGraph committee to decide, however.