fix(gateway): correctly route and persist Telegram Business inbox messages

[skiks]

Summary

• route Telegram Business inbox traffic passively instead of treating it like a regular interactive chat flow
• persist Telegram Business inbox payloads and archived text in the life inbox store
• ignore empty business payload fields and deduplicate business payload probe records
• add a payload probe script plus regression coverage for business inbox handling

Problem

When Hermes is attached to a Telegram Business account, business inbox messages are not handled like normal Telegram chat traffic. In practice this made business events hard to classify and inspect reliably: payloads could be duplicated, empty fields could leak into storage, and archived business text was not persisted in a form that made debugging or follow-up processing easy.

Scope

This PR intentionally stays focused on Telegram Business inbox detection, persistence, and diagnostics. The higher-level inbox workflow and action-card automation built on top of this layer are kept out of scope for a follow-up branch.

Testing

• /home/alen/.hermes/hermes-agent/venv/bin/python -m pytest tests/gateway/test_life_inbox_store.py tests/gateway/test_telegram_business_inbox.py tests/gateway/test_telegram_business_payload_probe_script.py -q

[alt-glitch]

Related to #26654 (Telegram Business delegated inbox support PR) and #26653 (feature request). This PR focuses on inbox detection, persistence, and diagnostics — the higher-level inbox workflow is out of scope per the PR description.

[teknium1]

Thanks for isolating Business updates from the normal agent path and adding substantial regression coverage.

Problems

• The implementation and tests target gateway/platforms/telegram.py, but current main moved that adapter to plugins/platforms/telegram/adapter.py in 560010547. The PR test imports the removed module at tests/gateway/test_telegram_business_inbox.py:9, so this needs a plugin-era port rather than a direct application.
• gateway/life_inbox_store.py:155 introduces HERMES_LIFE_HOME and persists under ~/.hermes-life; this bypasses profile-scoped Hermes state and uses a non-secret env var for behavior. AGENTS.md:102-106 requires behavioral configuration in config.yaml.
• resolve_life_inbox_db_path() requires a separate accounts.json registry, while scripts/telegram_business_payload_probe.py:26 defaults to a specific Telegram owner ID. That is not a generic Telegram Business setup path.

Suggested changes

• Port the handlers and tests to plugins/platforms/telegram/adapter.py; current main's plugin handler registration surface from 7c4cde9e8 is the relevant integration point.
• Rework state/configuration around config.yaml and get_hermes_home(), without user-specific account assumptions.

Automated hermes-sweeper review.

[teknium1]

gateway.platforms.telegram no longer exists on current main: 560010547 moved the adapter to plugins/platforms/telegram/adapter.py. Port this test and the implementation to the bundled-plugin path rather than restoring the legacy module.

[teknium1]

Do not add HERMES_LIFE_HOME as a user-facing behavior setting or place state in ~/.hermes-life. Use a documented config.yaml setting and profile-aware get_hermes_home() storage; otherwise named profiles can silently share or bypass inbox state.

[teknium1]

This hard-coded Telegram owner ID makes the shipped probe user-specific. Require an explicit account selection or derive the owner through the configured Business connection instead.