fix(cron): drop stale env-var override of persisted provider

[dpaluy]

What does this PR do?

Cron jobs were passing os.getenv("HERMES_INFERENCE_PROVIDER") as the requested arg to resolve_runtime_provider(), which short-circuited the resolver's own precedence (explicit arg → persisted config → env) and let stale shell/.env values outrank the user's saved provider.

Long-lived cron daemons inherit env from the shell that launched them, so a since-changed provider (e.g. DeepSeek) could keep firing for jobs that don't pin provider/model. Same bug class as commit f0b763c74 fixed for the TUI /model switch.

The fix passes only job.get("provider") and lets resolve_requested_provider fall through to persisted config and env in the documented order — restoring the precedence the resolver was designed around.

Related Issue

N/A — surfaced while debugging cron jobs running on a stale provider after a /model switch.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• cron/scheduler.py (run_job): drop or os.getenv("HERMES_INFERENCE_PROVIDER") from the requested arg passed to resolve_runtime_provider(). Add a comment explaining the precedence inversion to prevent the line from being re-added.

How to Test

1. Set a stale env override in the shell that launches the cron daemon: export HERMES_INFERENCE_PROVIDER=deepseek.
2. Switch the persisted provider via the TUI /model (or by editing cli-config.yaml) to a different one, e.g. anthropic.
3. Schedule a cron job without pinning provider: or model: on the job.
4. Before this fix: the job runs against deepseek (stale env wins).
   After this fix: the job runs against anthropic (persisted config wins, env is consulted only as a final fallback).

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs — closest is the closed fix(cron): fall back to auto-detect provider when explicit provider fails #4127 (different fix path, not a duplicate)
• My PR contains only changes related to this fix
• I've run pytest tests/ -q and all tests pass — not run; change is a one-line precedence fix without existing coverage to break
• I've added tests for my changes — no regression test added; happy to add one if reviewers want a focused unit test mocking resolve_runtime_provider precedence
• I've tested on my platform: macOS 15 (Darwin 25.3)

Documentation & Housekeeping

• N/A — no public API or config keys changed
• N/A — cli-config.yaml.example unchanged
• N/A — no architecture/workflow change
• N/A — single-line behavior fix, no platform-specific code
• N/A — no tool descriptions/schemas touched

[teknium1]

Salvaged via #19627 onto current main - your commit authorship was preserved. Thanks!