feat(compliance): fire badge issuance on owner_test runs (closes #4376)

[bokelley]

Summary

• Extract the per-version badge fan-out (membership-org resolution + processAgentBadges loop across SUPPORTED_BADGE_VERSIONS) from compliance-heartbeat.ts into a shared runBadgeFanOut() helper in services/badge-issuance.ts.
• Call the helper from the two owner-driven test paths immediately after recordComplianceRun():
  • member-tools.ts evaluate_agent_quality (full comply) for an agent owner — fires badges off the canonical write so an owner who just fixed compliance sees the badge update on the next page load.
  • registry-api.ts POST /registry/agents/:encodedUrl/storyboard/:storyboardId/run (single storyboard) — same effect for in-place storyboard re-runs from the dashboard.
• Verification-change Slack notifications stay scoped to heartbeat — owner runs already deliver the result via chat / HTTP response.

Why the helper reads getStoryboardStatuses() instead of trusting the run's own inputs

The single-storyboard endpoint (storyboard/:storyboardId/run) supplies only one storyboard status in dbInput. If the helper used those inputs verbatim, deriveVerificationStatus() would treat every other declared specialism as "failing" (its storyboard would be absent from the status map) and degrade unrelated badges as a side effect. Loading the merged latest state from agent_storyboard_status after recordComplianceRun() returns the correct picture for both partial owner runs and full heartbeat runs.

Test plan

• npx vitest run tests/unit/badge-fan-out.test.ts tests/unit/badge-issuance.test.ts — 17 tests pass.
  • New tests: no-op on empty specialisms, full-status load for partial runs, membership-lapse revoke path, per-version aggregation contract.
• npx tsc --noEmit -p server/tsconfig.json clean.
• After merge: spot-check a heartbeat run still emits the verification-change Slack DM (no behavior change there — same code path, just goes through the helper).

Closes #4376.

🤖 Generated with Claude Code