Run a timelock event subscriber alongside the hourly monitor #438

Epic: #437

Outcome

a continuously running worker observes indexed timelock events without changing
current alert delivery.

Scope

• Subscribe to the existing TimelockEvent entity, filtered by monitored chains and addresses.
• Persist event provenance and independent per-chain checkpoints; do not share TIMELOCK_LAST_TS.
• Reconcile bounded, paginated ranges through HTTP, including reconnects, restarts, and late
  indexing. Account for duplicate snapshots, equal timestamps, and changed block hashes.
• Add service supervision, heartbeat/head-lag checks, and ingestion timing. Keep pilot output
  local; do not send public alerts or invoke emergency actions.
• Compare completeness against HTTP scans and measure indexing, subscription, and recovery
  delays. Decide whether production uses supported WebSockets, HTTP polling, or both.

Acceptance criteria

real new timelock events are observed, controlled disconnect/restart/backlog tests
recover all expected events without duplicates, and a coverage/latency report identifies the
production transport. The existing successful connection probe is only a starting point.

Dependencies

None. Begin with the existing Envio deployment; no indexing change or paid upgrade is required for the observation pilot.

Related work

• Peg monitoring L3: GraphQL oracle-events alert consumer #302
• feat(pegs): L3 oracle-events consumer — stables/oracle_events.py (#302) #307
• Envio hosting constraints: https://docs.envio.dev/docs/HyperIndex/websockets

Include relevant behavior/failure tests and operational documentation in the implementation. Update monitoring metadata when monitor behavior changes.