kernel_workflow: surface target-backend + target-language authoring k…

[IzacharyI]

Summary

Cross-backend kernel port/migration runs (e.g. rewriting an fp8 a8w8 blockscale
GEMM from CK to FlyDSL) previously only surfaced the source backend's knowledge
card. The agent never pulled in the target language's general-GEMM authoring
docs, so the engineer re-implemented the new backend "blind" — boxed in by the
source card (or a narrow block-scale/expert card) instead of the target backend's
full authoring how-to.
This PR makes kernel_workflow knowledge-selection also surface the target
backend card and the target language's authoring documentation on any
cross-backend port — for any source→target pair (ck→flydsl, triton→tilelang,
hip→ck, …), not just ck→flydsl.

Root cause

• tech_lead analyze set kk_language = current (source) language and populated
  kk_refs only from the source backend card — no target-side refs.
• engineer / deep_engineer read/mined only backends/<KK_LANGUAGE>.md (source).
• Operator backend cards had no cross-links to the target language's authoring docs
  (e.g. the CK card never pointed at the FlyDSL authoring docs).

What changed (prompt + docs only — no runtime/kernel code)

Role prompts

• tech_lead.md (analyze): on a cross-backend port, keep kk_language = editable
  source, but kk_refs now ALSO includes (a) the target backend card
  operators/<op>/backends/<target>.md and (b) the target language's authoring
  how-to under languages/<dir>/, via an id→dir map:
  triton→triton_amd, hip→hip_cpp, ck→composable_kernel, asm→asm_mfma,
  flydsl→flydsl, tilelang→tilelang, gluon→gluon, hipkittens→hipkittens.
• engineer.md / deep_engineer.md: on a cross-backend rewrite, also read/mine the
  target backend card + target language authoring docs (same map).
  Operator cards (cross-links to the FlyDSL GEMM authoring docs)
• scaled_quant_gemm/backends/ck.md — new "Porting to FlyDSL (ck→flydsl)" section.
• scaled_quant_gemm/backends/flydsl.md, fused_moe_grouped_gemm/backends/flydsl.md,
  dense_gemm/backends/flydsl.md — "Authoring / optimizing a FlyDSL GEMM" links to
  authoring_gemm_levers / authoring_optimization / authoring_tile_programming /
  debugging.

Before → After (ck→flydsl fp8 blockscale)

• Before: analyze emits kk_refs = CK card only → engineer sees CK tuning knobs
  (which don't transfer) → reimplements FlyDSL blind.
• After: analyze emits CK card + FlyDSL SOTA card + FlyDSL authoring docs →
  engineer gets tiling / LDS / XCD-swizzle / epilogue levers, structure-first
  optimization workflow, the @flyc.kernel tile-programming model, and debugging
  triage for the target.

Scope / generality

Rules are written for any source→target migration via the id→dir map; ck→flydsl
is just the motivating case (a2b / c2d all covered).