#2545 verify-build upgrade gate skips hand-written extensions but reports succeeded

The verify-build model version/upgrade gate (check-upgrades and upgrade-path-test in verification/workflow-verify-build.yaml) only looks at manifest.yaml files under model/. A version bump in a hand-written extension (ssh/, issue-lifecycle/, cve/*, ...) gets no static or dynamic upgrade check. Both steps still report succeeded, so the attestation says the upgrade gate passed when nothing was checked.

Observed

On commit 41b980916 (branch fix/2336-ssh-sudo-chained), @swamp/ssh goes from 2026.07.28.1 to 2026.09.25.1 in both ssh/manifest.yaml and the model version, with a new upgrades entry. verify-build printed:

upgrade-verify │ No model manifest changes detected
upgrade-verify │ No model manifest changes — skipping upgrade path test

and recorded both steps as succeeded (Gate: 13/14 passed, 1 skipped). The one step counted as skipped was codegen idempotency, not these.

Cause: both steps build their list with git diff <merge-base> --name-only | grep manifest.yaml | grep ^model/ (around lines 276 and 348).

Why it matters

agent-constraints/implementation-conventions.md (Upgrade Path Verification) says the upgrade check is required whenever a change touches a model's version field or upgrades array. It only exempts brand-new extensions and vault/datastore extensions. Hand-written model extensions participate in the upgrade system and are where #554-style gaps (a version bump without an upgrades entry) happen. verification-conventions.md describes the gate as applying only to generated models, so the two docs disagree too.

This is the silent-uncovered failure that verification-conventions.md warns about for missing TARGETS entries: verification passes, the attestation says every check passed, and nothing was checked.

Expected

• The upgrade gate covers every changed manifest.yaml whose extension ships models, not just model/**.
• Or, when it deliberately skips, the step reports skipped with a reason and doesn't count as passed.

Either way, verification-conventions.md and implementation-conventions.md should agree on the scope.