fix(config+telegram): prevent duplicate config key and duplicate message delivery (#71047)

[webtecnica]

Fixes #71047

Problem A — hermes config set duplicates top-level config key

Running hermes config set platforms.telegram.streaming false appended a new platforms: block at EOF instead of editing the existing one, because set_config_value navigated on the raw user config (stripped of DEFAULT_CONFIG-only subtrees like platforms). The gateway reads the first block, so config set had no runtime effect — a silent, confusing failure.

Fix: Use load_config() (merged with DEFAULT_CONFIG) as the navigation base for _set_nested, so keys present only in defaults are found and mutated in-place. Write back only the raw user-set keys via atomic_yaml_write as before, preserving the contract of not dumping defaults.

Problem B — Streaming + reply_to_mode='first' duplicates final message

When streaming: true and reply_to_mode: 'first', the streamed preview is sent as a reply to the user. If the final edit fails (flood control), the fallback paths (_send_fallback_final and _send_empty_fallback_final) sent the completed answer as a fresh non-reply message, producing two visible messages — the reply-preview and the plain resend.

Fix: Preserve the reply anchor by passing reply_to=self._initial_reply_to_id on every fallback/continuation adapter.send() call, matching the first-send path at line 2224 that already passes it.

Files changed

File	Change
hermes_cli/config.py	Use load_config() as navigation base in set_config_value; write back raw config
gateway/stream_consumer.py	Pass reply_to=self._initial_reply_to_id on fallback send + continuation chunk send
tests/gateway/test_telegram_final_delivery.py	Assert reply_to kwarg in adapter.send calls

Tests

• tests/hermes_cli/test_set_config_value.py: 91/91 passed
• tests/hermes_cli/test_config.py: 186/186 passed
• tests/gateway/test_telegram_final_delivery.py: 10/10 passed
• tests/gateway/: 301 passed, 1 pre-existing failure (Honcho cache busting), 1 skipped

[alt-glitch]

This was generated by AI during triage.

Related: #71047 (config and Telegram report), #71077 (Codex replay pruning), and #71073 (Matrix encryption-state fallback). This omnibus combines three independently scoped fixes; the latter two have open focused PRs, so it is related rather than a duplicate.

[teknium1]

Thank you for tracing both delivery and config behavior. The Telegram fallback direction is useful, but the PR needs a focused rework before it can be salvaged.

Problems

• The config hunk still writes platforms.telegram.streaming, but current streaming resolution reads display.platforms.<platform>.streaming (gateway/run.py:4155; defaults at hermes_cli/config_defaults.py:1171). It therefore does not update the display.platforms value confirmed in Bug: config set duplicates top-level key + Telegram streaming+reply_to_mode='first' duplicates final message #71047.
• The added fallback assertions do not initialize initial_reply_to_id (tests/gateway/test_telegram_final_delivery.py:37-42), so reply_to is None does not test the reported reply_to_mode='first' path.
• The Matrix and Codex commits overlap the separately open focused PRs fix(matrix): fallback to homeserver query for room encryption detection (#71067) #71073 and fix(compression): prune stale codex_reasoning_items during compaction (#71058) #71077, as noted in the existing member discussion.

Suggested changes

• Canonicalize or reject the noncanonical config path and add a raw-config-to-runtime regression for display.platforms.telegram.streaming.
• Test fallback sends with a non-null initial reply anchor.
• Split the unrelated Matrix and Codex work from this salvage.

This is an automated hermes-sweeper review.

[zoser69]

Heads up: I opened #78111 as a focused fix for only Problem A of #71047 (the config set mis-targeted key), per the triage recommendation to keep that fix narrow and drop the unrelated Matrix/Codex changes.

#78111 redirects platforms.<name>.<display_setting> → display.platforms.<name>.<setting> (the path gateway/display_config.py::resolve_display_setting actually reads), and only for known display settings, leaving connection keys (token, extra, …) untouched. It includes a real-path test against a temp HERMES_HOME.

If the maintainers prefer to consolidate on a single PR, #78111's set_config_value redirect could be cherry-picked into this one (or vice versa). Either way, Problem A should land against the confirmed display.platforms hierarchy rather than writing to the top-level platforms block.