expand Tlon adapter support

[wca4a]

Summary

This PR expands the Hermes Tlon integration to match the OpenClaw/Tlon skill behavior tested locally.

• ports the Tlon adapter onto the latest gateway patterns
• adds OpenClaw-style group/channel read paths via channels /v2, chat /v3, groups /groups/ui, and groups /v1/foreigns
• matches OpenClaw SSE fallback dispatch so %channels group mentions are not dropped when Eyre omits a usable subscription id
• adds delayed top-level and thread-reply blob reads through channels/v4 and channels/v5
• makes group invite handling fail-closed while still accepting owner invites and queueing owner approvals
• adds DM history fallback polling so missed Tlon SSE DM events still get picked up
• keeps gateway shutdown/status notices routed to the owner DM instead of shared groups
• adds native Tlon management tools for groups, channels, roles/admin promotion, gallery/heap posting, history, contacts, raw scry/poke/thread operations, and blob/media handling
• adds direct group creation with verified admin assignment
• adds OpenClaw-style reaction approvals in Tlon: thumbs up approve, thumbs down deny, stop sign block/stop
• adds Tlon user documentation under the messaging gateway docs

Why

The previous Tlon adapter could send basic messages, but it did not fully mirror OpenClaw group/channel behavior. In practice that meant it could miss group mentions, did not reliably understand current group membership, could mishandle delayed blobs, could not populate galleries correctly, and forced approval flows through text commands instead of Tlon reactions.

Validation

Ran:

scripts/run_tests.sh tests/gateway/test_tlon_adapter.py tests/tools/test_tlon_tool.py

Result:

44 passed

Also copied the patched adapter into the local live Hermes runtime, ran py_compile, restarted the gateway, and confirmed Tlon reconnected cleanly.

[wca4a]

I split the Tlon work into a draft stack in the fork so the large integration branch can stay draft while each review surface is isolated:

1. Core platform adapter: feat(tlon): add core platform adapter wca4a/hermes-agent#2
2. Native Tlon tool/admin flows: feat(tlon): add native management tool wca4a/hermes-agent#3
3. Groups/channels read model: feat(tlon): align group and channel read model wca4a/hermes-agent#4
4. Media/blob/gallery posting: feat(tlon): add gallery media posting wca4a/hermes-agent#5
5. Session/restart/approval safety: fix(tlon): isolate restart and approval status routing wca4a/hermes-agent#6

Validation on the top branch:

scripts/run_tests.sh tests/gateway/test_tlon_adapter.py tests/tools/test_tlon_tool.py tests/tools/test_send_message_tool.py tests/gateway/test_restart_drain.py tests/gateway/test_restart_notification.py tests/gateway/test_session.py tests/test_toolsets.py

Result: 313 passed.

I am keeping #26300 as the draft integration branch rather than marking it ready.

[wca4a]

Follow-up fix pushed to the integration branch and split stack: channel thread replies now parse the OpenClaw/Tlon %channels r-reply.set.reply-essay event shape. That was the missing path for thread reply mentions that appeared in Tlon activity but did not route into handle_message.

Validation:

• split stack top focused suite: 222 passed
• integration branch adapter suite: 33 passed

[wundrellama]

Hey @wca4a — tested this PR with a moon hosted on a Native Planet box via Startram and hit a connection failure worth flagging before this merges.

Apparently Startram's reverse proxy sends duplicate Server headers in HTTP responses, which is technically malformed per RFC 9110. This was silently tolerated until aiohttp 3.13.4, which introduced strict singleton header enforcement in the C extension parser. The result is the gateway fails immediately on connect:

ERROR gateway.platforms.tlon: [tlon] Connection failed: 400,
  message="Duplicate 'Server' header found.",
  url='https://<ship>.startram.io/~/login'

The fix: aiohttp 3.13.5 (released 2026-03-31, PR #12302) reverted response parsing back to lax mode — duplicate headers on responses are ignored again, while request parsing stays strict. Pinning aiohttp>=3.13.5 in pyproject.toml is all that's needed.

Given how many of us use NP machines, it would probably affect a meaningful chunk of users. Happy to provide any additional detail if helpful.