feat(verification): per-major-version badge data model (#3524 stage 1)

[bokelley]

Summary

Stage 1 of #3524 — extends `agent_verification_badges` so an agent can hold parallel `(Spec)` / `(Live)` badges across AdCP minor versions (3.0, 3.1, 4.0…). The previous PK `(agent_url, role)` becomes `(agent_url, role, major_version)`.

No behavior change yet — the heartbeat still passes the default `'3.0'` to `processAgentBadges`. Stage 2 wires per-version fan-out, Stage 3 adds `/badge/{role}/{version}.svg`, Stage 4 splits panel rows by version, Stage 5 reshapes brand.json. This PR is purely the data-model groundwork.

The six WG-decision questions on #3524 were resolved in this comment before any code landed.

What this PR ships

• Migration 457 — adds `major_version TEXT NOT NULL` to `agent_verification_badges` with a temporary default of `'3.0'` so the backfill is safe, parses existing `verified_protocol_version` (`X.Y.Z` → `X.Y`), rebuilds the PK, drops the default so future writes must specify the version, and adds an index on `(role, major_version, status)`.
• DB layer — `AgentVerificationBadge` gains `major_version`. `upsertBadge` / `getActiveBadge` / `revokeBadge` / `degradeBadge` all take a `majorVersion` parameter. List queries order by `major_version DESC`.
• `getHighestVersionActiveBadge()` — new helper that powers the legacy `/badge/{role}.svg` URL. Embedded badges in the wild auto-upgrade to the most recent version the agent has earned without changing the URL (Q3 of the resolved-decisions thread).
• `processAgentBadges()` — accepts an optional `majorVersion` parameter (defaults to `DEFAULT_BADGE_MAJOR_VERSION = '3.0'`). Existing-badge lookups and writes are now scoped to that single version — a failing 3.1 run never touches a 3.0 badge and vice versa. This is the load-bearing isolation property.
• 4 new tests covering version-isolation: only-touch-version-under-test, upsertBadge receives the version, default fallback when callers don't specify, and membership-lapse only affects the version under test.

What this PR does NOT change

• The heartbeat job still calls `processAgentBadges()` without a `majorVersion` — defaults to `'3.0'`. Stage 2 wires per-version fan-out.
• Storyboards have no `since:` field yet. Added in Stage 2.
• Badge SVG labels still read "Media Buy Agent (Spec)" — version segment lands in Stage 3.
• Verification panel still renders one row per role. Stage 4 splits into one row per (role, version).
• brand.json enrichment shape unchanged. Stage 5 adds the `badges[]` array.

Test plan

• 4 new unit tests for version-isolation
• 89/89 existing verification + badge tests pass
• Migration applies cleanly against Postgres (CI runs `Built migrations against Postgres`)
• TypeScript typecheck clean
• No behavior change — old callers of `processAgentBadges()` still hit the default version, and `/badge/{role}.svg` still serves what it did before (now via `getHighestVersionActiveBadge`)

Review focus

• The migration's PK rebuild — pg holds the table-level write lock for the duration. `agent_verification_badges` is small (one row per badged agent, not one per request), so the lock window is brief, but worth a sanity check.
• The `majorVersion` default in `processAgentBadges()` — confirming this preserves Stage 1's "no behavior change" promise.
• Tests for the per-version filtering invariant — does the test surface miss any case where 3.0 and 3.1 should genuinely be touched together?

🤖 Generated with Claude Code