feat(CRITICAL): rewrite corex_gdn/moe/fa2 to use real ixformer dispatch

Sub168 log analysis proves:
- corex_gdn.py: dlopen /usr/local/corex/lib64/libcorex_gdn.so (decode)
- corex_moe.py: ix_moe_bridge → ixformer::infer 7-step fused MoE pipeline
  - topk_softmax → moe_gen_idx → expand → group_gemm(w13) → silu → group_gemm(w2) → combine
- corex_fa2.py: ixformer.functions flash_attn (packed/paged/chunked prefill + paged decode)

Previous corex modules were pure PyTorch fakes with matching log messages.
Now they actually call the ixformer C++ API via ix_moe_bridge.so.

computility-run.yaml aligned to Sub168: max-model-len=256000, max-seq-len-to-capture=32768

Source reference:
- upstream_ref/xllm/xllm/core/kernels/ilu/ixformer.h (C++ API declarations)
- upstream_ref/xllm/xllm/core/kernels/ilu/fused_moe.cpp (MoE call pattern)
- upstream_ref/xllm/xllm/core/layers/npu_torch/qwen3_gated_delta_net_base.cpp (GDN)
- dockerrizhi.txt lines 310-397 (Sub168 runtime log)

computility-run.yaml

@@ -8,7 +8,7 @@ command:
     - --served-model-name
     - llm
     - --max-model-len
-    - '80000'
+    - '256000'
     - --gpu-memory-utilization
     - '0.95'
     - --trust-remote-code
@@ -29,7 +29,7 @@ command:
     - qwen3
     - --enable-prefix-caching
     - --max-seq-len-to-capture
-    - '8192'
+    - '32768'
     - --dtype
     - half
 env: