chore(fuze): sync vendored repo-manifest schema with canonical

[claude]

Vendored .fuze/repo-manifest.schema.json was stale relative to the canonical copy at izzywdev/FuzeSDLC@main:governance/repo-manifest.schema.json. This repo's stale copy would reject fields the canonical schema allows, so gate-manifest (when enabled here) would red on valid manifests.

Keys that differed (canonical vs. vendored):

• properties.platformAuth.description — wording updated (opt-out framing)
• properties.platformAuth.properties.enforce — missing in vendored copy
• properties.platformAuth.properties.reason — missing in vendored copy

Validation performed: this repo's own .fuze/manifest.json was validated against the NEW (canonical) schema using Python jsonschema (Draft 2020-12, full schema validation, not a structural approximation) — VALID, no changes needed to the manifest.

No file other than .fuze/repo-manifest.schema.json was touched.

---

Generated by Claude Code

[izzywdev]

This PR no longer does what its body says, and the cause is structural. Auto-merge disarmed while this is sorted out.

What the diff actually is now

19 files, +18,185 / −18,185 — a perfectly symmetric count, which is the signature of a whitespace rewrite, not a schema sync. Two commits:

commit	what it did
f64bcbe	the intended change — 1 file, +39/−1, exactly as the body describes
b09b32a	chore(governance): reconcile managed files to FuzeSDLC v1 [skip ci] — auto-committed by governance-sync

Ignoring all whitespace, b09b32a's only semantic change is:

.fuze/repo-manifest.schema.json | 40 +----------------------------
1 file changed, 1 insertion(+), 39 deletions(-)

That is f64bcbe being reverted. The schema diff between base and head is now empty — this PR delivers zero schema change. What remains is 19 Python files converted CRLF→LF, which .gitattributes:13 (*.py text eol=lf) does mandate and whose own comment records "20 pre-existing CRLF .py files under services/orchestrator/ remain" — a real backlog, but not this PR's job.

That rewrite is also why CodeQL reported 21 new alerts including 1 critical: every line of 19 files looks changed, so pre-existing alerts re-surface as new. Its own summary hedges — "Alerts not introduced by this pull request might have been detected because the code changes were too large." No new vulnerability was introduced here.

Why the revert happened — and why re-pushing won't help

.fuze/repo-manifest.schema.json is a MANAGED file. governance-sync fetches the canonical at this repo's baselineRef and reconciles managed files to that, not to canonical main.

FuzeAgent .fuze/manifest.json  ->  baselineRef: v1
FuzeSDLC  git describe main    ->  v1-53-g78f9c8c

v1 is 53 commits behind main. So syncing a managed file to main is guaranteed to be reverted on the next governance-sync run. Force-pushing f64bcbe back would just lose the race again.

What this means beyond this PR

The same reconciliation runs on every sibling claude/vendored-schema-sync PR. Four of them already show +0/−0 — FuzeExecutive#46, FuzeKeys#112, FuzeMerchandize#35, FuzeX#49. Those are not PRs that found nothing to do; they are PRs whose fix has already been reverted to nothing. Two of them had auto-merge armed and would have merged as no-ops.

So the vendored-schema drift cannot be fixed by syncing the schema. The fix is to move baselineRef — cut/advance the tag, or bump repos to a current release — so that "reconcile to canonical" and "sync to canonical" mean the same thing. Until then, every managed-file sync in this fleet is a no-op with extra steps.

Holding this PR rather than re-pushing into the same revert.

---

Generated by Claude Code