refactor(agent): run the capture managers on one select loop

`gesture::manage` and `keyboard::manage` were the same 82-line loop: reconcile
when asked, skip the wait when a deadline has already passed, then a `biased`
select over shutdown, session events, the published plan, receiver requests,
the io gate, a registry change while a restore is owed, and the deadline. They
differed only in names and argument lists. Beside the loop each kept its own
`PendingRestore { token, retry_at }` and `wait_for_registry_change`.

`watchers::capture_manager::run` is the loop once, over a `CaptureManager`
trait with the six calls it makes. The state machines stay where they were and
stay different, as `capture_session.rs` says they must: gesture tracks many
slots under one shared weak receiver lease, keyboard tracks one slot and hands
a finished restore's lease to its successor, and each cancels its own way when
a session retires. `GestureManager` and `KeyboardManager` are thin adapters
over the unchanged `*ManagerState` types; `manage(context)` still exists, so
the tests that drive the real loop through it are untouched.

Unchanged: the `biased` arm order, and what ends the manager how (`Graceful`
only after a drained shutdown, `Unexpected` when a control-plane source
closes).

One difference between the two loops looked like drift and was not: gesture
compared its deadline against a bare `Instant::now()`, keyboard against
`tokio::time::Instant::now()`. Gesture imports `tokio::time::Instant`, so both
were the same type, and the only one `sleep_until` accepts.

Guard: agent-capture-manager-loop-owner flags a `ManagerCompletion` decided in
the gesture or keyboard watcher, including as loose tokens inside
`tokio::select!` (10 hits on the parent tree, 0 here).