feat(ci): install the canonical @fuze entrypoint

[izzywdev]

Installs the canonical @fuze entrypoint from FuzeSDLC. Part of a fleet-wide rollout — depends on izzywdev/FuzeSDLC#282, merge that first.

Why this repo needs it

@fuze was answered in exactly one repo (FuzeInfra). This repo's issue templates already say @fuze — please triage. and the baseline documents @fuze as the delegation handle, so the mention landed nowhere — and a mention nothing answers is indistinguishable from an agent that simply has not replied yet.

What lands

.github/workflows/fuze.yml — the canonical handler. Mention-triggered on issues, issue comments, PR reviews and review comments; gated to OWNER/MEMBER/COLLABORATOR; loop-guarded; deduped per issue.

No cluster credential of any kind. FuzeInfra's original is deliberately cluster-capable (prod kubeconfig, kubectl/helm/terraform, in-cluster runner). Copying that verbatim to 22 repos would have handed prod cluster credentials to every product repo. It is split instead: the privileged variant is a separate template installed only where .fuze/manifest.json declares clusterOps.enabled: true, which only FuzeInfra does. Verified on this repo before this commit was made — grep -cE 'KUBE_CONFIG|terraform|runs-on: staging' over the rendered entrypoint returns 0, and no fuze-cluster.yml exists here.

LLM routing, not a hardcoded endpoint. The original pins ANTHROPIC_BASE_URL to an in-cluster service DNS name that does not resolve from a GitHub-hosted runner — a verbatim copy would have failed DNS here. This routes through ./.github/actions/fuze-code-action → ./.github/actions/llm-endpoint, which probes the gateway and falls back to a direct vendor key.

allowed-bots is set to a named list (fuzeone-bot,github-actions,fuze-agent, never *). Automated workflows legitimately comment @fuze to hand work over, and without this claude-code-action aborts ~1s in with "Workflow initiated by non-human actor" — a failure that reads in a skimmed log exactly like a provider outage.

claude-auto-pr.yml → fuze-auto-pr.yml

Naming only. That workflow makes no LLM call — it is gh pr create and nothing else. Nothing was routed through LiteLLM and nothing was added.

The old file is removed, not left beside the new one: both trigger on a push to claude/** and both call gh pr create for the same branch, so keeping it is a duplicate-PR bug rather than a rename. The new trigger covers both claude/** (unchanged — claude-code-action still names its branches that way) and fuze/**; no prefix was dropped.

This repo's copy was a stale install-time snapshot, not a deliberate fork (only FuzeInfra's carries a fuze:fork stamp), so the replacement is also a strict upgrade — it brings the agent-PR identity chain (fuze-agent App token → bot PAT → GITHUB_TOKEN) that the old copy predates.

Required-check safety, verified across all 22 governed repos: no ruleset anywhere names a context emitted by this workflow. The complete distinct required-check set is 15 strings, none of them open-draft-pr or Auto-PR from claude branches; no classic branch protection exists anywhere, so that set is complete. Structurally consistent too — the workflow triggers only on push, so it can never report on a pull_request to the default branch.

Verification done on this repo before committing

• grep for the three privileged identifiers in the rendered entrypoint → 0 hits.
• fuze-cluster.yml absent.
• actionlint exit 0 on both files.
• runs-on: rendered from this repo's declared ci.runner, not the template's default — a runs-on naming a pool that does not exist does not fail, it queues forever.
• Rendered by the canonical installer engine (engine.reconcile → lib.render), so both files carry a fuze:managed marker and .fuze/installed.json records them. Identical bytes to what sdlc-bootstrap would write.

Not proven, and not provable right now: that a live @fuze mention completes. The fleet's ANTHROPIC_API_KEY is currently invalid (not merely exhausted), and mention mode deliberately does not attempt the OpenAI/Gemini rungs — so every @fuze / @claude mention hard-fails today regardless of routing. This PR fixes where the mention lands, not whether the credential works.

Why a PR and not a sync

governance-sync cannot push .github/workflows/** today and reports success when the push fails — 16 of 22 repos lack the code path entirely, and in the other 6 the commit-back is rejected 400 Duplicate header: "Authorization" while a missing set -o pipefail turns the failure green. See izzywdev/FuzeSDLC#283.

[github-actions]

Automated code review (gate-code-review)

• .github/workflows/fuze-auto-pr.yml:76 — jq '.[0].number' returns the string "null" when no PRs exist ([]), causing [ -n "$existing" ] to evaluate to true and exit before creating a PR

Report-only — this check never blocks merge.

[github-actions]

Automated code review (gate-code-review)

(none)

Report-only — this check never blocks merge.