Verdict: **Digest composed + sent, but send unconfirmed** — Telegram read-timeout x2 (flood-control on verbose life-manager topic). Likely delivered (maybe duplicated), not confirmed.
What ran:
- Pulled tickets (62 open / 12 high), today+7d calendar, reminders, MC-5120 bundle (3 candidates, backlog 24).
- Composed exception-based digest: 1 `I recommend` line (book Rowen return flight 17th + PC-as-fragile-goods, MC-5062), 2 more 48h items (Audi Menlyn tomorrow 09:00 MC-5039; NCC privileged-disclosure call MC-5076), quiet line (Investec→MC-5148, Inoxico→MC-5128), backlog count.
- MC-5014 shadow gate: recorded to ledger (`dry_run_notify`, `ledger_recorded:true`) — did **not** suppress scheduled send.
- `notify.py --topic life-manager`: rc=2 "read operation timed out" both attempts. Egress to api.telegram.org healthy (0.15s) → slow response = flood-control, not network. `sendMessage` hardcodes `timeout=10`, no timeout-retry.
- Froze after 2 fails (no 3rd fire = no 3rd dup).
- **Candidates NOT consumed** (per contract) — wa-technical-rev3, email-inoxico-questionnaire, digest-729d92b84547f199 stay pending; next scheduled digest reconciles.
- Step 4 state refresh: `{"marked": 0}`.
Root cause of unconfirmed-but-likely-delivered: `notify.py` returns False on read-timeout without capturing message_id, so a slow-but-successful Telegram POST is indistinguishable from a real failure. Durable fix = bump send timeout + add message_id idempotency (ops two-phase → route to a ticket, not inline).
Suggested next: leave it — the next hourly digest auto-reconciles the unconsumed candidates; I open an MC ticket to fix notify.py's timeout/idempotency so this stops recurring.
Want me to open that notify.py timeout-hardening ticket now? (yes/no)