feat(verification): per-version heartbeat fan-out + JWT adcp_version (#3524 stage 2)

[bokelley]

Summary

Stage 2 of #3524. Stage 1 set up the data model; this PR turns on the per-version issuance path.

Today with `SUPPORTED_BADGE_VERSIONS = ['3.0']`, runtime behavior is byte-for-byte identical to Stage 1 — but the wiring is in place. Flipping the constant to `['3.0', '3.1']` later turns on parallel-version badge issuance with no further code changes.

Architecture

A single `comply()` call still runs per agent (one network round per heartbeat). The flat storyboard-status list it returns is filtered per supported version before each `processAgentBadges()` call. Storyboards opt into a version via the SDK's existing `Storyboard.introduced_in` field — unset means "always applied," so today every storyboard is included for any 3.x target. When 3.1-only storyboards land they'll declare `introduced_in: "3.1"` and the 3.0 fan-out skips them.

What ships

• `SUPPORTED_BADGE_VERSIONS` in `services/adcp-taxonomy.ts` — the explicit on/off switch. Adding `'3.1'` is a deliberate decision, not auto-derived from storyboards (so a stray 3.1-tagged storyboard doesn't accidentally start issuing 3.1 badges before AAO is ready).
• `getStoryboardsForVersion(adcpVersion)` + `compareAdcpVersions` in `services/storyboards.ts` — the version filter. Numeric comparator (`'3.10' > '3.2'`), the same lesson Stage 1's review caught with the text `ORDER BY`.
• Heartbeat fan-out in `addie/jobs/compliance-heartbeat.ts` — iterates `SUPPORTED_BADGE_VERSIONS`, narrows storyboard statuses to the version's applicable IDs, calls `processAgentBadges` once per version. Notifications aggregate across versions for one notification per agent.
• JWT `adcp_version` claim in `services/verification-token.ts` — added to `VerificationTokenPayload` and signed alongside the existing claims. Validated at sign time against `^[1-9][0-9]*.[0-9]+$` so a poisoned DB row can't smuggle a malformed value into an AAO-signed token. Per Q4 of the resolved decisions, `protocol_version` (full semver) stays as informational metadata; `adcp_version` is the load-bearing badge identity claim.

What does NOT change

• Badge SVG label still reads "Media Buy Agent (Spec)" without a version segment — Stage 3.
• Verification panel still renders one row per role — Stage 4.
• brand.json enrichment shape unchanged — Stage 5.

Test plan

• 12 new unit tests across 3 test files
  • `compareAdcpVersions`: 6 cases including the load-bearing `'3.10' > '3.2'` invariant
  • `getStoryboardsForVersion`: catalog filter contract, predicate equivalence with the comparator
  • `SUPPORTED_BADGE_VERSIONS`: shape, type guard
  • JWT `adcp_version` round-trip, omit-when-absent, drop-on-malformed (SQL-injection-shaped + leading-zero), double-digit minor preservation
• 121/121 unit tests pass total
• TypeScript typecheck clean
• Heartbeat behavior with `SUPPORTED_BADGE_VERSIONS = ['3.0']` is identical to pre-Stage 2 — same single round of badge issuance per agent

Review focus

• The aggregation of `issued` / `revoked` across the per-version loop in the heartbeat — is the single combined notification the right call, or should each version fire its own?
• The filter ordering: `introduced_in` unset → always applied. A future contributor adding a 4.0 storyboard MUST tag it `introduced_in: "4.0"` or it will get tested against 3.0 agents. The contract is documented; whether to additionally require non-empty `introduced_in` for new storyboards is a separate policy decision.

🤖 Generated with Claude Code