fix(send_message): honor markdown_support config for QQ platform (#26697)

[briandevans]

Summary

• tools/send_message_tool.py::_send_qqbot hardcoded msg_type: 0 (plain text) for every QQ endpoint, ignoring the markdown_support config in pconfig.extra.
• Mirror the gateway adapter's pattern: when markdown_support is True (default), use {"markdown": {"content": ...}, "msg_type": 2} for the C2C and group endpoints. Plain text falls back to msg_type: 0.
• The guild channel endpoint keeps the simpler {"content": ...} shape that gateway/platforms/qqbot/adapter.py::_send_guild_text already uses.

The bug

Steps from the issue:

1. Configure QQ with markdown_support: true in config.yaml.
2. Use send_message to deliver a markdown table to a QQ C2C or group chat.
3. The message arrives as raw markdown — pipes, dashes, and asterisks visible — because the tool path sends msg_type: 0, not the markdown payload the QQ Open Platform expects.

Meanwhile the gateway adapter (gateway/platforms/qqbot/adapter.py:209) reads markdown_support from extra (default True) and _build_text_body (2596–2620) emits the correct markdown.content + msg_type: 2 shape. The tool path didn't, so the two ingress paths disagreed about how to render the same message.

The fix

Read markdown_support (default True) from pconfig.extra and build the v2 (C2C/group) payload the same way the adapter does. The guild channel endpoint payload becomes a plain {"content": ...} (no msg_type) to match _send_guild_text and avoid sending the unsupported markdown shape there.

markdown_support = bool(extra.get("markdown_support", True))
if markdown_support:
    v2_payload = {"markdown": {"content": content}, "msg_type": 2}
else:
    v2_payload = {"content": content, "msg_type": 0}
channel_payload = {"content": content}

Test plan

• New regression test: tests/tools/test_send_message_qqbot_markdown.py (5 cases — C2C markdown, group markdown, C2C plain when flag=False, default-True when flag unset, channel-endpoint shape unchanged). All pass under uv run --with pytest --with pytest-xdist --with pytest-asyncio.
• Regression guard: each test would fail against main — pre-fix code has payload = {"content": ..., "msg_type": 0} with no markdown field and no markdown_support lookup, so all four "msg_type == 2" / "markdown.content" assertions would KeyError or fail.
• Adjacent suite: tests/tools/test_send_message_*.py failures are pre-existing aiohttp-not-installed baseline (CI install pulls it via .[all,dev]); none touch _send_qqbot.

Sibling code paths that may need the same fix: none observed — the QQ adapter already honors markdown_support for C2C/group, and the guild channel API doesn't use msg_type in either path. The C2C and group payloads in _send_qqbot are now consistent with _build_text_body in the adapter. Happy to widen if a similar msg_type divergence shows up elsewhere.

Related

• Fixes [Bug] send_message tool ignores markdown_support config for QQ platform #26697

[briandevans]

CI audit — all 4 test failures are pre-existing baselines unrelated to this PR's touched code (tools/send_message_tool.py, tests/tools/test_send_message_qqbot_markdown.py).

Test	Symptom on CI	Root cause on main
tests/hermes_cli/test_gateway_service.py::TestSystemUnitHermesHome::test_system_unit_uses_target_user_home_not_calling_user	PermissionError: [Errno 13] Permission denied: '/root/.hermes/node/bin'	hermes_cli/gateway.py injects target-user PATH entries via Path.is_dir(), which surfaces EACCES on the CI sandbox's /root/.hermes/node/bin before any return. Fix in flight on PR #26640.
tests/hermes_cli/test_gateway_service.py::TestSystemUnitHermesHome::test_system_unit_remaps_profile_to_target_user	PermissionError: [Errno 13] Permission denied: '/root/.hermes/profiles/coder/node/bin'	Same Path.is_dir() EACCES surface, profile-scoped path. Same fix on PR #26640.
tests/tools/test_transcription_dotenv_fallback.py::TestProviderSelectionGate::test_explicit_xai_sees_dotenv	AssertionError: assert 'none' == 'xai'	After e13c1b806, xAI credential resolution moved into tools.xai_http.resolve_xai_http_credentials(); the test still only patches hermes_cli.config.load_env, not the new tools.xai_http.get_env_value entry point.
tests/tools/test_transcription_dotenv_fallback.py::TestEndToEndRegressionGuard::test_xai_key_only_in_dotenv_before_fix	assert False is True	Same root cause — _transcribe_xai reaches the xAI key through the same resolver now.

All four reproduce on clean origin/main and appear on the other open PRs in the same window (#26640, #26669). Happy to re-run CI once these land.

[briandevans]

Closing this to keep the contribution queue manageable while it awaits maintainer review. The fix still applies cleanly and I'm happy to reopen if a maintainer wants to pick it up — just give it a nudge and I'll refresh it against main.