Good fix for a real issue — the list/resolve asymmetry where Hermes emits Alice (dm) but won't accept it as input was a paper cut for agentic flows that copy target labels from send_message(action="list") output.

The structural improvement is solid: _channel_target_name() as the single source of truth for the display label, used by BOTH the listing path AND the resolution path, so they stay in sync by construction. Eliminates the possibility of drift. The removal of the ad-hoc target.rsplit(" (", 1)[0].strip() workaround in cron is also nice cleanup.

One structural concern — reaching into send_message_tool's private API:

from tools.send_message_tool import _parse_target_ref

_parse_target_ref is a leading-underscore private function in send_message_tool.py. After this PR, cron/scheduler.py depends on its signature and return contract. If someone refactors send_message_tool.py (renames, inlines, or changes the return tuple), cron silently breaks — and nothing in the private function's module warns about cross-module dependencies.

Two cleanups:

Option A — promote to public API by dropping the underscore prefix. Signals "other callers depend on this":

# send_message_tool.py
def parse_target_ref(platform_name: str, target_ref: str) -> tuple[Optional[str], Optional[str], bool]:
    """Parse a tool target into chat_id/thread_id and whether it is explicit."""
    ...

Option B — extract to a shared utility (tools/target_refs.py or similar). This is cleaner since _parse_target_ref contains platform-specific regex knowledge that arguably belongs in a platform-refs helper, not the send_message tool module.

Either way, the import from cron stops reaching past the underscore.

Minor observation — the resolution flow re-parses after resolving:

parsed_chat_id, parsed_thread_id, is_explicit = _parse_target_ref(platform_key, rest)
# ... set chat_id, thread_id from parse ...
resolved = resolve_channel_name(platform_key, chat_id)
if resolved:
    parsed_chat_id, parsed_thread_id, resolved_is_explicit = _parse_target_ref(platform_key, resolved)
    if resolved_is_explicit:
        chat_id, thread_id = parsed_chat_id, parsed_thread_id
    else:
        chat_id = resolved

This is correct (the resolver can return -1001:17585 which needs parsing to preserve the thread_id), but the double-parse is a bit tangled. A helper like _coerce_to_chat_thread(platform_key, ref) that encapsulates the parse-or-fallback logic would make the cron site read better:

chat_id, thread_id = _coerce_to_chat_thread(platform_key, rest)
resolved = resolve_channel_name(platform_key, chat_id)
if resolved:
    chat_id, thread_id = _coerce_to_chat_thread(platform_key, resolved)

Ship it — the user-visible behavior is correct, tests exercise the important cases, and the refactor is a net improvement over what was there.

Merged via PR #5288 (consolidated bugfix salvage). Your commit(s) were cherry-picked onto current main with your authorship preserved in git log. Thanks @damianpdr for the fix!