Revamp release pipeline

[drbh]

This PR revamps the build pipeline in a couple ways:

• Consolidate 6 build-pr-* / build-release-* workflows into 3 unified platform
  workflows (build.yaml, build-mac.yaml, build-windows.yaml) controlled by a mode
  input (pr / release)
• Single dispatch entrypoint (dispatch.py) used by PR triggers, release
  triggers, bot commands, and local CLI
• Thin dispatch workflows for PR open/sync and PR merge that resolve the kernel
  and call dispatch.py
• Windows builds gated by a WINDOWS_KERNELS allowlist in the dispatch script
  instead of dispatching everything and skipping at runtime
• Backends passed as a workflow input - removes fragile PowerShell TOML regex
  parsing
• build-and-upload renamed to build-and-stage, uploads to kernels-staging;
  merge-and-upload / release remain the production path
• All workflows accept a repo_prefix input for configurable upload destination
• Removed manual-build-upload.yaml, per-kernel needs_oneapi tracking, and XPU
  block list (all absorbed into the above)

---

Main change explained

dispatch.py is now called in CI on both new PR's and when a PR is merged, or by the comment bot. It will read the kernel's build toml and then trigger the correct build-*.yaml workflows. For example, if a kernel is only supported on osx, it will only call the build-mac.yaml workflow.

additionally the build-*.yaml workflows now always expect to be trigged manually, and expect certain input arguments. one of those arguments is mode which is either "pr" or "release", this way we can reuse the same workflow for both testing a PR, or when its merged to main and needs a release.

ways to trigger the dispatch.py

├── build-pr-dispatch.yaml (PR opened/synced → mode=pr)
├── build-release-dispatch.yaml (PR merged → mode=release)
├── pr_comment_kernel_bot.py (bot comments)
└── CLI (local invocation)

workflows it triggers

├── build.yaml (Linux: cuda, cpu, rocm, xpu)
├── build-mac.yaml (macOS: metal)
└── build-windows.yaml (Windows: cuda, xpu — allowlisted kernels only)

note you can also see what arguments a workflow would trigger with via the cli like

python .github/scripts/dispatch.py flash-attn4 --dry-run --mode release

Skipping Windows build for flash-attn4 (not in WINDOWS_KERNELS allowlist)

[dry-run] build.yaml:
{
  "ref": "main",
  "inputs": {
    "kernel_name": "flash-attn4",
    "dispatch_key": "flash-attn4-build.yaml-2d9dee4ce329",
    "mode": "release",
    "backends": "cuda",
    "repo_prefix": "kernels-community"
  }
}

Dispatched (1):
  - build.yaml (key: flash-attn4-build.yaml-2d9dee4ce329)

Skipped (2):
  - build-mac.yaml
  - build-windows.yaml

or

python .github/scripts/dispatch.py relu --dry-run --mode release

[dry-run] build-windows.yaml:
{
  "ref": "main",
  "inputs": {
    "kernel_name": "relu",
    "dispatch_key": "relu-build-windows.yaml-b4b19432c7db",
    "mode": "release",
    "backends": "cuda,xpu",
    "repo_prefix": "kernels-community"
  }
}

[dry-run] build.yaml:
{
  "ref": "main",
  "inputs": {
    "kernel_name": "relu",
    "dispatch_key": "relu-build.yaml-c8e094345cdc",
    "mode": "release",
    "backends": "cpu,cuda,rocm,xpu",
    "repo_prefix": "kernels-community"
  }
}

[dry-run] build-mac.yaml:
{
  "ref": "main",
  "inputs": {
    "kernel_name": "relu",
    "dispatch_key": "relu-build-mac.yaml-28e8dcfac8e7",
    "mode": "release",
    "backends": "metal",
    "repo_prefix": "kernels-community"
  }
}

Dispatched (3):
  - build-windows.yaml (key: relu-build-windows.yaml-b4b19432c7db)
  - build.yaml (key: relu-build.yaml-c8e094345cdc)
  - build-mac.yaml (key: relu-build-mac.yaml-28e8dcfac8e7)

---

Lastly this change also updates the kernel-bot to use dispatch.py too, and adds a new "build-and-stage" command. This command can be used on a PR to build the contents of that PR and then push the build output to kernels-staging/kernel-name

ie just add a comment like the following to a PR (in this case one with changes to relu)

/kernel-bot build-and-stage relu