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.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 41.06%. Comparing base (294c0a0) to head (648acad).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #190   +/-   ##
=======================================
  Coverage   41.06%   41.06%           
=======================================
  Files          81       81           
  Lines        6171     6171           
  Branches      252      250    -2     
=======================================
  Hits         2534     2534           
  Misses       3634     3634           
  Partials        3        3           

Flag	Coverage Δ
backend	41.06% <ø> (ø)
frontend	41.06% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.