hermes - 💡(How to fix) Fix feat(cron): ability to reset cron job model/provider override back to default

Problem

When a cron job has a per-job model and provider override set, there is no way to reset them back to null (i.e., "use the default model from global config") via the cronjob tool's update action.

This means once you set a custom model for a cron job, you can never switch it back to the default without deleting and recreating the job — which loses job history (run count, last status, etc.).

Proposed Solution

Allow setting model=null and provider=null (or default?) via cronjob update to clear the per-job override and make the job fall back to the global default model.

Example via tool:

cronjob(action='update', job_id='<id>', model=null, provider=null)

Example via CLI:

hermes cron edit <job_id> --model null --provider null

After this, the job should use the default model from config.yaml.

Alternatives Considered

1. Delete and recreate the job — works but loses job history (run count, last status, output files).
2. Dedicated clear_model flag — e.g., cronjob(action='update', job_id='<id>', clear_model=true). More explicit but adds a new parameter.
3. Accept empty string as "reset" — e.g., model='', provider=''. Simpler but less explicit than null.

The proposed solution (null) is the most intuitive — it's the natural opposite of setting a value.

Reproduction Steps

1. Create cron job with custom model: cronjob(action='create', name='test', prompt='...', schedule='0 7 * * *', model='gemma4:e4b', provider='lmstudio')
2. Verify model is set: cronjob(action='list') → shows model: gemma4:e4b
3. Try to reset: cronjob(action='update', job_id='<id>', model=null, provider=null)
4. Check again: cronjob(action='list') → still shows model: gemma4:e4b (NOT reset)

Related Issues

• #12658 — Named LLM model entities
• #22761 — Model/provider corruption