Dev/huizzhan/flydsl gdn k6

[huizzhan]

Summary

A standalone FlyDSL K6 (output projection), signature-compatible with the Triton
chunk_fwd_o_opt_vk so the two can be swapped at the call site. Motivation: the
separate K5+K6 pipeline still runs the Triton output stage, which grows from 12%
of the pipeline at batchhead=8 to 49% at 512 -- the main reason the separate
path loses to the fused kernel at high batchhead.

Two structural differences from the K6 half of the fused kernel:

• Chunk-parallel grid. The fused kernel walks chunks serially because K5's
  state recurrence forces it to. K6 carries no cross-chunk state, so the chunk
  index becomes a grid axis and low batch*head stops being occupancy-starved.
• Triton's pair gate exp(g_i - g_j) rather than the fused kernel's
  telescoping exp(g_i - g_last). The fused form is only cheap because K5 hands
  it a pre-gated v_new for free; here v_new arrives ungated from HBM, so that
  form would cost a column gate over v and put a >= 1 factor on the critical
  path that overflows f32 once a chunk's decay exceeds ~88. The pair form is
  evaluated only under the causal mask, where g_i <= g_j bounds it by 1.

Performance (gfx950, seqlen=8192, K=V=128)

Landed at 0.87–1.19x Triton, up from 0.30x at first correct version:

batch*head	Triton (us)	FlyDSL (us)	speedup
8	33.5	28.2	1.19x
64	165.5	162.1	1.02x
512	1428.1	1603.2	0.89x

Three optimizations got it there, each aimed at a different cap:

1. q out of LDS. It is the A operand of both GEMM3 and GEMM4a and the M=BT
   axis is already split across waves, so a wave only reads its own 16 rows --
   nothing to share. LDS 88 -> 72 KiB, which fits a second CTA per CU.
2. XOR swizzle on the LDS tiles. The dominant cost. A B-operand read of a
   [rows, 256B] tile has its 16 lanes exactly 256 B apart, i.e. 0 mod 32 banks
   -- every lane on bank 0, a 16-way conflict on the hottest read in the kernel.
   BV=64 went 4538 -> 1597us.
3. NR_SPLIT, widening the CTA along N. At BV=128 the LDS footprint is
   structural (h, k, v and A must all be shared), so CTAs/CU cannot improve;
   splitting N over a second set of waves doubles resident waves at the same
   footprint. 1919 -> 1591us, making BV=128 the gfx950 default.

BV=64 now runs at 4.56 TB/s, ~88% of roofline, so the residual gap at high
batch*head is traffic rather than scheduling.

Test plan

• op_tests/test_flydsl_gdn_o.py -- 75 cases, all passing. Given identical
  h/v_new, FlyDSL and Triton agree to an RMSE ratio of 0..1.8e-5 across
  varlen and dense, tail chunks, GQA, g and gk gates, both exp/exp2
  paths, and BV in {32, 64, 128} (128 covers the NR_SPLIT=2 path).
• Strong-decay regression (-5/token, ~-320 cumulative per chunk) guarding
  the gate-form choice above.
• op_tests/flydsl_tests/bench_k6_flydsl_vs_triton.py for the table above.
• Not yet wired into chunk.py -- the call site still uses Triton K6, so
  this lands dormant. Enabling it is a follow-up.