docs(telegram): document Bot API 10.0 guest mode media delivery

[elphamale]

Summary

• Documents the native guest_message/answerGuestQuery reply flow (Bot API 10.0) added by feat(telegram): guest mode two-phase reply (Bot API 10.0, text-only) #56476 and feat(telegram): guest mode deliver_<token> media flow #56477: the two-phase stub → edit behavior, and the deliver-token media button flow for files that can't be attached directly to a guest reply.
• Adds TELEGRAM_HOME_CHANNEL config docs (staging chat required for cached-file delivery) and the documented limitations (10-minute delivery-token TTL, no session stickiness across guest turns).

Why

The existing guest_mode section only covers the pre-Bot-API-10.0 @mention bypass. The native two-phase reply and media delivery behavior shipped in #56476/#56477 has no user-facing documentation, so operators have no way to know what TELEGRAM_HOME_CHANNEL does or why a "tap to receive" button shows up instead of an inline file.

Requires

• feat(telegram): guest mode two-phase reply (Bot API 10.0, text-only) #56476 (two-phase guest reply)
• feat(telegram): guest mode deliver_<token> media flow #56477 (guest-mode deliver_ media flow, stacked on feat(telegram): guest mode two-phase reply (Bot API 10.0, text-only) #56476)

This PR documents behavior that doesn't exist on main yet — please merge those first, or review this as a preview of the docs that will land alongside them.

How to test

• cd website && npm run build (or yarn build) to confirm the docs page builds without broken links/MDX errors.
• Manual read-through: is the guest-mode media flow understandable to someone who hasn't seen the code?

Platforms tested

Docs-only change, no runtime platform testing applicable.

[teknium1]

Thanks for documenting the operator-facing behavior of the proposed guest-media flow.

Problems

• Current main only has the mention-bypass implementation (plugins/platforms/telegram/adapter.py:6713-6720, :7443-7465) and its corresponding guide section (website/docs/user-guide/messaging/telegram.md:1044-1070). It does not yet implement guest_message, answerGuestQuery, or the media delivery-token flow documented here.

Suggested changes

• Keep this docs change paired with the canonical implementation from the still-open #56476/#56477 stack, and validate the final wording against the landed implementation before it is merged.

Automated hermes-sweeper review.

[teknium1]

This section describes behavior that current main does not provide: the existing adapter implements only the guest_mode mention bypass. Please land this alongside the selected #56476/#56477 implementation and validate the final behavior against it.

[elphamale]

Pushed d0c6df89a — rebased onto current main and re-validated the wording against the #56476/#56477 stack as it stands after review, per the sweeper's condition. Two statements had drifted from the implementation:

Caller authorization was undocumented. #56476 gained a fail-closed caller gate during review (credit @mazzz3r): the chat is gated by mention, but the person mentioning must also pass the bot's normal user authorization — allowlist/pairing union, * as the explicit open-to-everyone opt-out, empty allowlist denies everyone, and unauthorized callers are denied silently (gateway log warning only). Added a "Who can use it" paragraph covering this, including the operator-facing symptom: a silent bot during testing usually means the tester isn't allowlisted, not an outage.

"No session stickiness" was no longer accurate. The session-isolation fix keys guest sessions per chat + caller (default group_sessions_per_user: true), so repeat mentions from the same person deliberately continue their conversation while different askers in the same group stay isolated. Reworded the limitation bullet and the pre-existing guest_mode paragraph to state what actually holds: the @mention is required every turn (no auto-engagement), but per-caller memory persists; deliver-button token redemption is independent of session state.