fix(discord): anchor handoff threads in parent channel

[SEStarkman]

Summary

• create Discord handoff threads from a visible parent-channel seed message
• preserve direct channel-level thread creation as the fallback
• persist successful handoff thread IDs in the participation tracker so mentionless replies continue when thread_require_mention=false
• preserve mention gating when thread_require_mention=true, plus DM and failed-create behavior

Root causes

1. create_handoff_thread() preferred parent.create_thread(), producing an anchorless public thread that Discord mobile did not expose reliably in the parent timeline.
2. Both successful handoff creation paths returned without calling self._threads.mark(thread_id), so continuable cron threads were absent from discord_threads.json and mentionless replies were dropped before session routing.

Verification

• TDD regression reproduced: 3 expected failures before the tracker fix (seed persistence, fallback persistence, mentionless continuation)
• scripts/run_tests.sh tests/gateway/test_discord_send.py tests/e2e/test_discord_adapter.py -q (34 passed)
• scripts/run_tests.sh tests/cron/test_scheduler.py tests/gateway/test_discord_*.py tests/e2e/test_discord_adapter.py -q (765 passed)
• .venv/bin/ruff check plugins/platforms/discord/adapter.py tests/gateway/test_discord_send.py tests/e2e/test_discord_adapter.py
• .venv/bin/python -m py_compile plugins/platforms/discord/adapter.py tests/gateway/test_discord_send.py tests/e2e/test_discord_adapter.py cron/scheduler.py
• git diff --check
• independent Codex review: no blockers

Deployment

No migration or config change. Restart the Hermes gateway after installing/checking out the merged version; this PR does not restart, update, merge, or deploy anything.

[teknium1]

Thanks for addressing both the discoverability and continuation-state gaps. The current-main premise is verified: plugins/platforms/discord/adapter.py:5498-5507 creates an unanchored thread and :6212-6220 requires the id to be in _threads before permitting mentionless replies.

Problems

• plugins/platforms/discord/adapter.py:5519 sends the visible seed before seed_msg.create_thread(). If that call fails, the direct fallback at :5540 succeeds but leaves the seed in the parent timeline even though it does not anchor the returned thread. The PR's own fallback test at tests/gateway/test_discord_send.py:545-572 exercises this exact sequence without checking cleanup.

Suggested changes

• Keep the seed message and, after a successful direct fallback, best-effort delete it or revise it to make the unanchored fallback explicit. Add an assertion to the fallback test.

Automated hermes-sweeper review.

[teknium1]

If seed_msg.create_thread() failed after the send at line 5519, this direct fallback returns an unanchored thread while leaving a visible “Hermes handoff” seed that does not open it. Please retain the seed and best-effort delete it (or edit it to accurately describe the fallback) after direct creation succeeds; extend the fallback test to cover that outcome.

[SEStarkman]

Confirmed and fixed in 789076d25. The adapter now retains the seed, marks the successfully created direct-fallback thread, then best-effort deletes the stale seed. Discord cleanup refusal is debug-logged and cannot turn a successful fallback into failure.

Regression coverage now asserts both successful deletion and cleanup-failure/non-fatal behavior; the anchored path and participation tracking remain covered.

Verification:

• scripts/run_tests.sh tests/gateway/test_discord_send.py tests/e2e/test_discord_adapter.py -q — 35 passed
• scripts/run_tests.sh tests/cron/test_scheduler.py tests/gateway/test_discord_*.py tests/e2e/test_discord_adapter.py -q — 747 passed
• .venv/bin/ruff check plugins/platforms/discord/adapter.py tests/gateway/test_discord_send.py tests/e2e/test_discord_adapter.py — passed
• .venv/bin/python -m py_compile plugins/platforms/discord/adapter.py tests/gateway/test_discord_send.py tests/e2e/test_discord_adapter.py cron/scheduler.py — passed
• git diff --check — passed

[Majber]

The seed-message-first path is a good improvement, but the direct fallback still has a correctness gap.

discord.TextChannel.create_thread(..., message=None, type=None) defaults to ChannelType.private_thread in discord.py. The fallback currently calls:

thread = await create(
    name=thread_name,
    auto_archive_duration=1440,
    reason=reason,
)

Therefore, when the visible seed path fails but direct creation succeeds, Hermes can create a private thread instead of the intended public continuable thread. We reproduced this against the installed discord.py signature/source; type is None is normalized to ChannelType.private_thread.

Please make the direct fallback explicit:

thread = await create(
    name=thread_name,
    type=discord.ChannelType.public_thread,
    auto_archive_duration=1440,
    reason=reason,
)

Suggested regression assertion:

assert create_thread.await_args.kwargs["type"] is discord.ChannelType.public_thread

We currently carry this one-line fix locally; it applies cleanly to current origin/main and is covered by the focused Discord regression suite.