Agent-callable run signals: abort/steer + active-run discovery

[ReganBell]

Closes parity gap #1 from the UI↔agent capability audit: the web UI can stop or steer a running turn (POST /v1/runs/:id/signal, source-only), but the agent had no path — even though strictPostAllowed already carved out a /v1/run-signals/ prefix that no route ever used. This wires up that intended route.

• POST /v1/run-signals/:id (auth: either) — {kind:"abort"} or {kind:"steer", text}. Viewer is derived from the capability token's principal (or portal identity for source callers) and enforced through the existing viewerMayUseRun gate; a run outside the caller's reach answers 404.
• GET /v1/run-signals/active?threadRef= (auth: either) — viewer-bound active-run discovery, so the agent can find the run it's being asked to stop.
• Catalog: new family in agent-api-catalog.ts so the agent knows the routes exist.
• Tests: capability-token accept/steer, cross-principal 404, no-token 401, validation, viewer-bound discovery. Existing run-signal-route tests untouched and green.

No behavior change for source-auth callers. The strict-posture allowlist already permitted this prefix; this PR only adds principal-scoped handlers behind it.

Validated the gap live before building: a capability-token POST to /v1/runs/:id/signal 403s with "capability token not valid for this route".

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[ReganBell]

Closing — owner decided this capability isn't needed, and parity work will land in the private fork instead.