[Feature]: (Performance) Implement async two-phase MoE execution (begin/end) for CUDA backend

[RaphyTwin]

Problem

In the metal backend we have an elegant async execution model (coli_metal_moe_block_begin / _end), allowing the CPU/SSD to fetch missed experts while the gpu computes the resident ones. The CUDA backend (backend_cuda.h) currently only exposes synchronous blocking execution calls like coli_cuda_expert_group, missing out on parallelizing disk-I/O with GPU execution.

Proposed solution

Introduce a two-phase async API for the CUDA backend similar to Metal:
Implement coli_cuda_moe_block_begin and coli_cuda_moe_block_end.
Use non-default CUDA streams (cudaStream_t) to execute math kernels on resident experts on the gpu asynchronously.
While the gpu compute stream is busy, the host thread can continuously upload newly fetched experts to the GPU using asynchronous memory copies (cudaMemcpyAsync) on a separate copy stream.

Alternatives considered

No response

Scope and compatibility

No response

[JustVugg]

Reasonable for the CUDA backend. Splitting MoE into begin (kick off expert loads/uploads + async matmul launch) and end (sync + combine) would let the host keep routing the next layer while the GPU works — classic latency hiding. It pairs naturally with #251 (async I/O) and #253 (GDS): begin issues the streaming reads, end consumes them. Right now the CUDA path (#131/#199) is synchronous per expert-group. Keeping open — this is the CUDA-side counterpart to the CPU pipeline that #257 just added for Windows. Whoever picks it up: the combine step must preserve the exact accumulation order for token-identical output vs the CPU path.

[JustVugg]

This is part of the same picture as #431 (decode pays ~54 ms/token in CUDA API choreography). An async begin/end MoE that overlaps the expert-group launches with the CPU-side routing/staging is one of the pieces that collapses the 1,490-launch flood. #434 (COLI_CUDA_RESID=1, keep expert-group results on device) is the first merged-pending step. Sequencing matters: RESID first (fewer D2H copies), then the begin/end split, then the one-graph decode. Want to land these as an ordered series each with its own byte-identical + tok/s gate? That's how #298/#421 went in cleanly.