Persist inbound platform reply metadata

[ITMINDSCAPE]

Summary

Persist inbound platform correlation metadata alongside user transcript rows so gateway features can reliably resolve native replies after a restart.

Each inbound MessageEvent can now persist:

• platform
• chat ID
• incoming message ID
• replied-to message ID

platform_message_id remains a separate indexed column for deduplication and lookup.

Implementation

• add an additive messages.platform_metadata JSON/TEXT column through the existing declarative schema reconciler
• thread metadata through gateway, turn-context, standard agent, Codex, proxy, queued-follow-up, and early-failure persistence paths
• preserve metadata across append, transcript replacement/compaction, export, and import
• decode structured metadata only on raw transcript reads
• strip platform metadata, message IDs, and the internal DB persistence marker from provider-bound message copies without mutating stored history
• append new optional parameters after existing positional parameters to preserve API compatibility

Tests

• tests/test_hermes_state.py: 470 passed, 1 skipped
• focused gateway/agent/Codex/provider-projection suites: 90 passed
• Ruff and git diff --check: passed

A full scripts/run_tests.sh run was also attempted locally. It reported 27 failures in unrelated macOS/system-integration suites. The four agent/auth failures inspected separately reproduce unchanged on a clean upstream worktree; none involve the files or behavior changed here.

[teknium1]

Thanks for tracing the ordinary, proxy, queued-follow-up, and early-failure persistence paths. The underlying gap remains on current main: gateway/run.py:16656 forwards only event_message_id, gateway/session.py:3085 persists only the platform message ID, and the canonical messages schema at hermes_state_common.py:192 has no structured platform-metadata column.

Problems

• hermes_state.py:7196 carries replacement metadata in a map keyed only by platform_message_id. Because the proposed metadata contains platform and chat scope, duplicate IDs from different scopes can overwrite one another during replace_messages() and restore the wrong reply target.

Suggested changes

• Preserve by a scoped identity such as (platform, chat_id, message_id) rather than message ID alone.
• Salvage against the current state-schema, portability, and TurnContext seams; GitHub currently reports this branch conflicting and 865 commits behind main.

This is an automated hermes-sweeper review.

[teknium1]

This carry-forward map is keyed only by platform_message_id, although the metadata is explicitly platform/chat scoped. A duplicate ID from another chat or platform can overwrite this entry and restore the wrong reply correlation during replace_messages(); please use a scoped key or retain row-specific metadata.