chore(a2a-maintain): verify + fix FuzeFront's A2A surface config

[izzywdev]

Summary

Ran gate_a2a.py --all (FuzeSDLC scripts/gate_a2a.py) against this repo's already-built per-product A2A pod chart and fixed the real gaps it found. No secret values were read, printed, or written anywhere in this change — only secretRef {name,key} references and a SealedSecrets-directory declaration.

• Image: a2a.image.repository corrected from ghcr.io/izzywdev/fuzeagent-a2a (abandoned 2026-08-24, no longer built) to ghcr.io/izzywdev/fuze-a2a (what FuzeAgent's release.yml actually builds/publishes, and what its own a2a-shared/values-prod.yaml uses). values-prod.yaml's tag re-pinned to a plain, currently-live, anonymously-verified-pullable CI tag (624956d8983b) instead of a tag@digest compound the registry API can't resolve as a single reference. Base values.yaml now declares tag: "latest" (the sanctioned dev-shape value) instead of an empty string.
• Creds: added governance/a2a-policy.json (seeded from the FuzeSDLC canonical) declaring FuzeFront's actual SealedSecrets directory (deploy/contabo/sealed) — both referenced secrets (a2a-card-signing/jws.key, fuzefront-secrets/LITELLM_MASTER_KEY) already exist there; the gate's default sealedSecretDirs just didn't know to look there. Also carries the fleet-approved skills-adoption ratchet already naming FuzeFront's real skills gap.
• Auth: base values.yaml no longer declares an empty-valued auth: block while the pod is disabled (the contract requires oidcIssuerUrl whenever auth is present at all) — commented out, mirroring FuzeAgent's own a2a-shared base shape.
• Docs: docs/a2a/README.md corrected the stale image name and flagged that its "deployment — devops-engineer, not yet built" section is actually done, plus a still-open cross-repo question for platform-governance/devops-engineer (see below).

Verification

$ python3 gate_a2a.py FuzeFront --all
gate-a2a: repo=izzywdev/FuzeFront a2a=enabled values-docs=2 policy=governance/a2a-policy.json adoption=ratcheted
::error::gate-a2a I1  (x2 — image.repository mismatch)
::warning::gate-a2a S3  (zero bundle skills — ratcheted)
gate-a2a: 3 finding(s), 2 fatal

The 2 remaining fatal I1 findings are known, already-flagged gate/standard-doc staleness: gate_a2a.py's default policy and governance/a2a-runtime-standard.md in FuzeSDLC still name ghcr.io/izzywdev/fuzeagent-a2a as the one shared image; that repository is abandoned and the real one is ghcr.io/izzywdev/fuze-a2a (verified independently: fuzeagent-a2a GHCR package inactive since 2026-08-24 vs. fuze-a2a updated on every FuzeAgent release through today, and it's what FuzeAgent's own release workflow, chart, and docs consistently use). This is already flagged upstream (FuzeAgent PR #257) — not fixed here since fixing it would mean pointing FuzeFront back at the stale/dead image.

S3 (zero bundle skills on app-shell-platform) is a real, unresolved gap — no .claude/skills/* bundle in this repo genuinely documents the role's actual domain behavior (Module-Federation host shell / app registry / heartbeat / shell surface); they're all generic SDLC-process skills. Rather than force-fit one, it's left as the fleet-owner-approved ratcheted debt item it already is.

Also verified: helm lint and helm template both clean for values.yaml and values-prod.yaml; role.json validates against agent-templates/schema/role-manifest.schema.json; .fuze/manifest.json validates against .fuze/repo-manifest.schema.json; providesTo already exactly matches the pre-staged a2a-dependency-graph.json backfill (no diff needed); root CLAUDE.md already present.

NEEDS PRODUCT/OPERATOR

• A real skill bundle for app-shell-platform — someone who owns the domain (frontend-engineer/backend-engineer) needs to author .claude/skills/<name>/SKILL.md describing the role's actual product knowledge, then add it to role.json skills[].
• Sealing/rotation of a2a-card-signing / fuzefront-secrets stays devops/operator territory — not touched here, only referenced by name.
• FUZEFRONT_MCP_URL provisioning and the MCP-gateway service-identity gap (an A2A-invoked session has no browser-originated caller token to forward) are named in docs/a2a/README.md §1/§3 — owned by backend-engineer + appsec-reviewer, not this pass.

OUT OF SCOPE — NOT DONE

• Cross-repo architecture conflict: FuzeAgent's deploy/helm/a2a-shared/values-prod.yaml also lists a FuzeFront tenant entry (behind that file's own "STILL DO NOT MERGE" GO-LIVE gate). If that rollout proceeds while this repo's own per-product pod stays enabled: true, the same tenant name would be served by two pods. Flagged in docs/a2a/README.md; resolving it is platform-governance's/devops-engineer's call, not decided here.
• Live pod verification — the prod cluster is unreachable from this session; nothing here claims a pod is actually running.
• Cluster application of any of this — Prod is GitOps; this PR is config only.

[github-actions]

fuze-code-review — automated verdict

No verdict was reached — this run is NOT an approval.

fuze-code-action conclusion was 'failure', not 'success' — no review was produced, so none can be approved. See the per-rung 'fuze-code-action' notices in the job log for the specific classification (availability / task / declined) and, on an availability failure, the named provider error that triggered it.

This is reported as a failed check deliberately: a review that could not run must never be silently indistinguishable from a clean one.