Parent and architecture

• Implementation epic: #6
• Architecture: #1
• Depends on: canonical finalization #23, Telegram ingress adapter #36, Telegram control plane #8

Outcome

Make the existing Telegram sender project canonical assistant events through the durable frontend-projection boundary without owning result content or history.

Estimate

• 3 SP / 2 engineering days
• Risk: medium

Scope

• Consume a generic frontend projection record referencing a canonical assistant event.
• Resolve the authorized Telegram binding and render bounded text/file messages.
• Preserve delivery claim, retry/backoff and dead-letter behavior.
• Keep Telegram message IDs and post-send ambiguity as transport delivery facts.
• Ensure delivery TTL expiry cannot erase canonical assistant/tool history.
• Reject tenant, binding, session, event and attachment mismatches before send.
• Update sender documentation and projection tests.

Verification

• Delivery retry does not duplicate the canonical assistant event.
• A stale or cross-tenant binding/event reference cannot be sent.
• Missing/archived/revoked bindings follow explicit retry or terminal policies.
• Text and attachment projections preserve canonical payload digests.
• Physical post-send ambiguity is documented and reconciled without claiming exactly-once Telegram delivery.

Acceptance criteria

• Telegram consumes canonical events as a projection frontend.
• Canonical result history survives Telegram delivery state expiry.
• The sender contains no canonical conversation/session ownership.
• This issue is independently schedulable after generic finalization.

Non-goals

• Worker finalization.
• Telegram external ingress edge #17.
• Physical exactly-once Telegram sends.
• WebUI projection.