fix(cron): manual runs no longer silently drop media attachments

[victor-kyriazakos]

Summary

hermes cron run <job-id> could deliver a cron job's text output while dropping its PDF/image attachments, with the run still reported as successful. Scheduled runs of the same job delivered both. Reported by an enterprise customer on v0.20.0 whose managed crons deliver reports to Slack DMs; the underlying defects are present on current main.

This PR makes attachment failures visible in the run status on both delivery lanes, and applies the same media path policy in every process, so one-off test runs behave like scheduled runs.

Root cause

Scheduled and manual runs share the same delivery body (run_one_job → _deliver_result), and a clean-environment reproduction delivers attachments correctly on both paths. The field failure comes from three related gaps:

1. The standalone lane discarded upload failures. Platform standalone senders (Slack files_upload_v2, Discord, ...) report per-file upload failures in result['warnings'] while returning success: True for the delivered text leg. _deliver_result read only result['error'], so the run was marked ok, the text arrived, and the attachment disappeared without a trace in the run status.
2. The live-adapter lane did the same. _send_media_via_adapter logged failed sends at WARNING and returned None, so the caller had nothing to record either.
3. Media path policy differed by process. gateway.strict, media_delivery_allow_dirs, and trust_recent_files were translated from config.yaml into the environment variables validate_media_delivery_path reads only during gateway startup. A manual run executes in the CLI process, which never runs that translation — in strict or allowlisted deployments it filtered attachment paths under different settings than the gateway process and dropped files a scheduled run would deliver.

On v0.20.0 the failure had an additional layer: the isinstance(resp, dict) gates fixed by 9cf2cbd (shipped in 2026.8.13) meant Slack upload failures were not even detectable in the sender. That commit fixed detection; this PR fixes visibility and policy parity.

Changes

• _deliver_result surfaces standalone-sender warnings into delivery_errors, which reach the job's last_error and the cron run output, with target context.
• _send_media_via_adapter returns per-file error strings (failed sends, unavailable loop, policy-dropped paths) and the live-adapter call site records them. A run that delivered text but not its attachment now reports a partial failure on either lane.
• New gateway/media_policy.apply_media_policy_env() holds the config-to-env translation previously inlined in gateway startup. Gateway boot delegates to it unchanged; _deliver_result applies it before filtering, so all processes filter under the same configured policy. Attachments dropped by the policy filter are reported in the run status with a pointer to the relevant config keys.

No new environment variables, config keys, or tools. The helper moves existing translation; already-set environment values keep precedence, so operator overrides are unaffected.

Validation

Check	Result
New suite tests/cron/test_media_delivery_parity.py (8 tests)	Written first: 6 fail on unpatched main, 8 pass after
Field-shape reproduction (strict via .env, allowlist via config.yaml)	Unpatched drops the attachment as reported; patched delivers it
Full gates: tests/cron, shutdown drain, send_message, media suites	923 passed, 0 failed, 1 skipped
Mutation check (warnings loop disabled, bridge disabled)	Exactly the 2 guarding tests fail; restore returns green

Controls: clean delivery still returns no error; media still reaches the sender; both edited files syntax-verified.