Hub API token janitor for out-of-process leak paths

## Summary

PR #133 closes the in-process harness exit paths for #109 (fail-closed token revocation on intermediate stage failure). Two leak paths remain that the harness **cannot** cover — they require a controller-side or Hub-side janitor:

1. **Pod killed without defers running (OOM / node loss / preemption).** The harness never executes its revocation defer, so the token survives until TTL.

2. **Intermediate success where the next stage never runs.** The current stage succeeds and correctly preserves the token for the next stage, but that stage is never created (controller create failure, AgentWorkflowRun deleted between stages, etc.). No process ever revokes the token.

Both cases leave a valid Hub API token dangling until TTL expiry.

## Possible approaches

- **Controller finalizer on AgentRun / AgentWorkflowRun:** revoke any associated token when the resource is deleted or transitions to a terminal state without a successor stage.
- **Hub-side TTL sweep:** periodic cleanup of tokens past their expected lifetime, independent of harness signaling.
- **Combination:** controller best-effort + Hub sweep as backstop.

## Context

- #109 — original issue (harness-side fix landed in #133)
- #133 — `:bug: Fail-closed token revocation on intermediate stage failure`

Read issues #109 and #133 first to understand the existing token-revocation behavior and the limits of the harness fix. Then investigate the controller-side and Hub-side lifecycle entry points described here; the work is complete when tokens from killed workloads or missing successor stages no longer remain valid until ordinary TTL expiry.

Written by the indexing model from the issue text.