fix(simplex): add polling fallback for missed chat items

[Zoffka]

Summary

Fixes SimpleX inbound reliability when the daemon does not push newChatItem events to the persistent WebSocket client.

The adapter now:

• starts a lightweight /tail 50 polling fallback alongside the persistent WS listener
• keeps poll latency bounded with short poll-specific connect/command timeouts
• persists seen item keys across gateway restarts in ~/.hermes/simplex_seen_items.json
• uses per-chat seen keys (direct:<contactId>:<itemId>, group:<groupId>:<itemId>) instead of globally treating itemId as unique
• dispatches polled unread items in background tasks so polling is not blocked by agent response time
• unwraps resp payloads for newChatItem, newChatItems, and chatItems
• resolves SimpleX send targets through /chats all display-name targets, surfacing chatCmdError instead of silently reporting success

Why

Some simplex-chat daemon versions/modes keep the persistent WebSocket connection open but do not deliver fresh chat-item push events to every connected client. Hermes then appears silent until restart/reconnect, despite messages being visible in simplex-chat /tail.

Polling /tail 50 gives Hermes a deterministic fallback path, while persisted per-chat seen keys prevent stale backlog replay after restarts and avoid DM/group itemId collisions.

Test Plan

• python -m pytest tests/gateway/test_simplex_plugin.py -q
• python -m py_compile plugins/platforms/simplex/adapter.py tests/gateway/test_simplex_plugin.py
• git diff --check

[alt-glitch]

Overlaps with #26480 (SimpleX WebSocket reliability), #26433 (3 SimpleX bugs), and #27120 (idle WebSocket reconnect fix). All four PRs address SimpleX inbound message reliability from different angles. Consider consolidating.

[Zoffka]

Closing for now while we finish root-causing the SimpleX daemon/poller interaction. We will open a cleaner PR once the fix is properly scoped and verified end-to-end.