hub: no drained_at timestamp, so stub-to-drain latency is unmeasurable - add one column to cursors

OPS-228 carried an acceptance criterion I could not satisfy from persisted state: 'measure how often the stub is followed by a drain in the same turn.' The primitive does not exist. cursors is CREATE TABLE cursors (agent TEXT PRIMARY KEY, read_id INTEGER NOT NULL DEFAULT 0) - no timestamp column at all - and nothing anywhere in the hub records a delivered_ts/drained_ts pair for a message. So the interval between a stub notification and the drain that follows it is not derivable after the fact, by any query, on any window. I answered the criterion by naming the gap rather than estimating a number, and decided the stub on structural grounds instead (it IS the wake path; an idle Claude Code -cc session has no next tool result for a message to arrive on - see memory no-wake-path-for-idle-cc-agents). WHAT WOULD MAKE IT MEASURABLE: a drained_at column on cursors, written on each read_unread, plus a notified_at the shim already knows at :740. The delta between them is the quantity OPS-228 asked for, and it also answers a standing family of questions - how long a message sits buffered, whether the nudge interval (NUDGE_INTERVAL_MS, default 10000) is doing anything, and whether an agent that looks idle is actually undrained. THIS IS A HUB CHANGE, not a shim change, so it is a separate row by construction: it needs a schema migration on /var/lib/llmmsg-srv/v2.sqlite and a write path in hub.mjs. Scope it as one column plus one UPDATE; do not let it grow into a delivery-telemetry table.