fix(gateway): thread a real task_id through post-stream media delivery and cron tasks

[elphamale]

What does this PR do?

Stacked on #47716 — this branch is built on top of that PR's, so the diff
below includes its 5 commits until #47716 merges. Only the last commit
(fix(gateway): thread a real task_id through post-stream media delivery and cron tasks) is this PR's own; the file-level review should focus there.

Follow-up to #47716. That PR added Docker container→host path translation for
MEDIA: file delivery, but several call sites have no task_id available, so
translate_docker_media_paths() degrades to mount-table-only translation and
only proceeds when exactly one Docker terminal environment is active
gateway-wide — with zero or multiple concurrently active environments (as on
any busy multi-session deployment) it no-ops and the file is dropped, even
though the run that actually produced it is still alive and its environment
still resolvable by its own task_id.

Reproduced in production: a Telegram guest-mode reply's buffered "OPC"
flush (guest mode buffers the whole reply and delivers it as a single edit at
turn end, not via live streaming) routes through
gateway/run.py::_deliver_media_from_response — one of the task-id-less
paths. Across three separate turns in the same guest chat, the agent
correctly emitted MEDIA:/home/.../cache/videos/....mp4, and each time the
gateway log showed Skipping unsafe MEDIA directive path — the video was
silently dropped, with only the text reply delivered.

This PR threads a real task_id through the two paths where the producing
task genuinely is identifiable: the post-stream media rescan, and cron jobs.

Related Issue

Addresses #64889 for the two paths listed below.
Not filing as Fixes #64889 — the issue's third path
(gateway/platforms/base.py's generic handle_message() / weixin.py's
send()) is intentionally left open; see "Deliberately out of scope."

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• run_agent.py: AIAgent.run_conversation() already computes its own
  effective_task_id before calling into
  agent.conversation_loop.run_conversation(). It now surfaces that value as
  result["task_id"] on every dict return (the exception path re-raises and
  never returns a dict, so no other branch needs touching) — any caller
  holding the turn's result dict can recover the exact task_id that
  produced it, the same way already_sent/failed already work.
• gateway/run.py: _deliver_media_from_response() takes an optional
  task_id parameter and forwards it into translate_docker_media_paths().
  Its one caller now passes agent_result.get("task_id").
• cron/scheduler.py: run_job() now passes task_id=str(job_id) into
  agent.run_conversation(), so a cron job's own terminal environment is
  deterministically identifiable by its own job id instead of an unrelated
  random UUID generated fresh per run. _send_media_via_adapter() already
  receives the full job dict — it now reads job["id"] back as that same
  task_id (previously the function's own comment noted this was not the
  real task_id; it now is).

Deliberately out of scope

gateway/platforms/base.py's generic handle_message() and weixin.py's
send() still can't identify the producing task without a larger contract
change: both receive their text from self._message_handler(event), and
MessageHandler is typed to return a plain Optional[str] — the full
agent_result dict (and its new task_id key) never reaches this layer.
Threading it through would mean changing that protocol's return type across
every platform adapter that registers a handler, which is exactly the kind of
"bigger than a bug fix" shared-contract change #47716 itself declined to
bundle (see that PR's "Why this isn't in #47716" note). Left degraded,
unchanged from before this PR — still tracked by #64889.

How to Test

1. scripts/run_tests.sh tests/run_agent/test_run_agent.py tests/gateway/test_post_stream_media_delivery.py tests/cron/test_scheduler.py tests/agent/test_subagent_lifecycle.py —
   all pass, including four new tests covering explicit/auto-generated
   task_id surfacing, forwarding into translate_docker_media_paths, and
   the cron job-id threading.
2. Manual repro of the original bug: enable a Docker terminal backend, start
   a Telegram guest-mode chat, have the agent create a video file and reply
   with a MEDIA: tag while at least one other, unrelated terminal
   environment is concurrently active elsewhere on the gateway. Before this
   fix: video silently dropped (Skipping unsafe MEDIA directive path in the
   log) whenever zero or 2+ environments are active gateway-wide at flush
   time. After: delivered, because translation now resolves this turn's own
   environment directly by its own task_id regardless of what else is
   running.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes
• I've tested on my platform: Linux (Ubuntu, x86_64)

Documentation & Housekeeping

• N/A — no config keys, docs, or tool schemas changed; no architecture/workflow change to CONTRIBUTING.md/AGENTS.md
• Cross-platform impact considered — this is Python dict/string plumbing only, no OS-touching code

Screenshots / Logs

Live log excerpt from the reproduced failure, before this fix:

WARNING gateway.platforms.base: Skipping unsafe MEDIA directive path: /home/hermes/.hermes/cache/videos/insta_....mp4
WARNING hermes_plugins.telegram_platform.adapter: [Telegram] guest OPC flush (chat=... buffered_len=26 turn_media=False imi=...)

turn_media=False on every flush confirms the guest-mode media staging
function was never reached — the file never survived path translation to get
there.

[teknium1]

Thanks for tracing the post-stream task identity through the gateway; that path matches a real current-main limitation (gateway/run.py:18393-18394).

Problems

• Blocking: the cron path still loses container-local media before the new task-bound lookup runs. At cron/scheduler.py:1525-1527, _deliver_result() extracts media, uses unscoped translation, and filters it. Under the multi-environment case described by this PR, that filter drops the unchanged container path. The later task-bound translation at cron/scheduler.py:1342-1344 therefore receives no media.

Suggested changes

• Thread str(job["id"]) into the translation at cron/scheduler.py:1526 before the first filter, or move filtering to the task-bound helper. Add a two-active-Docker-environment regression proving a container-only cron attachment reaches the adapter.

Automated hermes-sweeper review.

[teknium1]

This task-bound translation is too late for cron delivery: _deliver_result() already calls task-id-less translation and filter_media_delivery_paths() at lines 1525-1527. In the multiple-environment case, that earlier filter drops the container path, so this helper receives an empty list. Pass the job task_id into the earlier translation (or defer filtering) and cover that ordering with a regression test.

[elphamale]

Re-scoped this PR following @teknium1's guidance on #94441 (thanks for flagging it there rather than letting it re-derive independently).

What changed and why:

The original approach here (thread task_id through _default_docker_workspace_host_root/_docker_persistent_home_host_root to resolve <sandbox>/docker/<task_id>/...) is now fully superseded by #94560, which fixed the actual root cause behind #93950/#64889: persistent Docker was never supposed to be per-session at all — it's one container per profile. That PR rewrote the resolution into _docker_sandbox_dir_candidates(session_key), keyed by profile name. Re-threading task_id into that mechanism today would resolve a directory that mostly doesn't exist under the corrected architecture, so that whole approach is dropped from this PR.

What's kept — a still-open gap, independently re-confirmed against current main:

_docker_sandbox_dir_candidates()'s own docstring already explains why it takes session_key explicitly rather than reading it ambiently: delivery code runs after the turn's _profile_runtime_scope has often already exited (#93950), so an ambient lookup can silently resolve the wrong profile. But the function's primary candidate still calls get_active_profile_name() — an ambient lookup — while session_key only ever feeds the legacy fallback candidate. The same class of bug the docstring warns about, just not fully closed out.

Separately, I traced the actual call sites and found two in gateway/run.py that thread no identity at all today: _deliver_media_from_response (the post-stream MEDIA rescan) and the delegate-task background-result delivery path both call filter_media_delivery_paths(media_files) bare. Same for cron's _send_media_via_adapter/_deliver_result. None of these were touched by #94437/#94509/#94560.

This PR now:

• Adds an explicit profile: Optional[str] = None parameter alongside session_key on _docker_sandbox_dir_candidates and everything in its call chain, used in place of the ambient lookup when the caller has it.
• Threads SessionSource.profile/session_key (via _session_key_for_source) explicitly through both gateway/run.py call sites, derived from data carried on the event/source object itself — not from a contextvar, so it's correct regardless of whether _profile_runtime_scope is still active at that point.
• Threads the job's own id as session_key through cron's two delivery functions, matching this PR's original identifier construction — cron's own per-profile-process design (see _get_hermes_home()'s docstring) made ambient profile lookup a plausibly-safer bet there, so I left profile on ambient fallback for cron rather than inventing a value with no verified source on the job dict.

All changes are additive (new optional params, defaults preserve existing behavior for every other caller) — squashed to one fresh commit against current main since the old approach shared essentially no code with what's here now.

Open question I didn't want to resolve unilaterally: is ambient get_active_profile_name() actually reliable at cron's delivery call sites in a multiplexed gateway, or does cron need the same explicit-profile treatment I gave the gateway path? I traced the gateway path concretely enough to be confident; cron's dispatch architecture (per-profile ticker process vs. a shared multiplexed one) I could not fully verify either way without more time in that code. Flagging rather than guessing.