fix(gateway): stamp observed group transcript rows with epoch floats

[smalever]

Fixes #118105.

Problem

The observe paths stamped the transcript entry with datetime.now(tz=timezone.utc).isoformat().
hermes_state_messages._coerce_timestamp → hermes_cli.timefmt.coerce_epoch trusts numbers,
numeric strings and datetime — but not a string spelling of one — so every observed row was
persisted with a substituted fallback and logged:

WARNING hermes_cli.timefmt: Ignoring corrupt message timestamp '2026-09-21T09:59:17.532760+00:00'

222 of them in one day in a Telegram group running observe_unmentioned_group_messages, in
errors.log — the WARNING+ channel operators read to find real problems.

Approach

Stamp time.time(), matching every other append_to_transcript caller (gateway/run_turn.py
already did). Three sites, the whole class:

• plugins/platforms/telegram/adapter.py::_observe_unmentioned_group_message
• gateway/platforms/yuanbao.py::GroupAtGuardMiddleware._observe_group_message
• gateway/platforms/yuanbao.py recall system note

time is already imported in both modules; no new imports, no behaviour change beyond the stored
value being the adapter's own stamp instead of a fallback.

Excluded: gateway/mirror.py also builds an ISO timestamp key, but _append_to_sqlite never
forwards it to append_message — a dead field, not a corrupt write. Fixing it is a separate
question (drop the key or wire it through) and does not belong in this diff.

Tests

tests/gateway/test_observed_transcript_timestamp.py, parametrized over the Telegram and Yuanbao
observe paths. It asserts the relationship rather than a snapshot: the entry an observe path
produces is written through the real SessionDB and read back, and the stored value must equal
what the adapter stamped, with no Ignoring corrupt message timestamp in the log.

Sabotage run (restoring .isoformat() at both sites) — both parameters fail on pre-fix code:

FAILED tests/gateway/test_observed_transcript_timestamp.py::test_observed_group_message_timestamp_survives_the_write_path[telegram]
FAILED tests/gateway/test_observed_transcript_timestamp.py::test_observed_group_message_timestamp_survives_the_write_path[yuanbao]
  assert stored == pytest.approx(float(written), abs=1e-6)
  WARNING hermes_cli.timefmt:timefmt.py:38 Ignoring corrupt message timestamp '2026-09-21T10:37:51.269468+00:00'

With the fix, via scripts/run_tests.sh:

tests/gateway/test_observed_transcript_timestamp.py
tests/gateway/test_telegram_group_gating.py
tests/hermes_state/test_corrupt_row_robustness.py
=== Summary: 3 files, 32 tests passed, 0 failed (100% complete) ===

Risk

Low. The stored instant moves by microseconds (fallback was the write time); no schema, API or
config change. Readers are untouched — coerce_epoch keeps degrading genuinely corrupt rows to ?
as before.