feat(cron): expose per-job Model field in Create/Edit Job modal

[nujovich]

Summary

The cron scheduler already resolves a per-job model override
(cron/scheduler.py: model = job.get("model") or os.getenv("HERMES_MODEL") or "").
The cron UI did not expose it, so users either accept the gateway
default or hand-edit ~/.hermes/cron/jobs.json. Hand-editing is
fragile: the gateway rewrites the file on each tick, so the user has
to stop the gateway to make the edit stick.

This PR adds a free-text Model (optional) input to the Create and
Edit Job modals, wired into the existing create/update payload under
the model key.

Screenshots

Create Job modal

Before	After

Edit Job modal (After shows the field pre-filled from the job's model)

Before	After

A note (I was not sure if backend supports model)

The PUT path forwards the whole updates dict, so model round-trips.
But the POST handler whitelisted fields (prompt/schedule/name/deliver/skills) and
CronJobCreate had no model field, so a frontend-only change would
have been silently dropped on create. I added the minimal forward
(2 lines): model on CronJobCreate + passing it to create_job()
(which already accepted the kwarg). Happy to split that into its own
commit/PR if you'd prefer the UI and backend forward to land
separately.

Files

• web/src/pages/CronPage.tsx — Model input in both modals, state,
  payload wiring (create omits empty; edit clears to null).
• web/src/lib/api.ts — model on the create/update payload types and
  on the CronJob interface.
• web/src/i18n/{types,en}.ts — optional modelOptional /
  modelPlaceholder keys + English strings, following the existing
  optional-key + ?? fallback pattern (other locales fill in later).
• hermes_cli/web_server.py — model on CronJobCreate + forwarded
  in the POST handler.

Question for maintainers

Three viable UX shapes — I want your call before I iterate:

1. Free text (this PR). User types moonshotai/kimi-k2.6 or any
   string. Smallest change, no model-registry dependency.
2. Dropdown populated from the gateway's known models (whatever
   list /model or the providers config exposes). Requires a backend
   endpoint to expose that list.
3. Autocomplete combining (1) and (2): free text with suggestions
   from the known list.

I shipped (1) because it's the minimal change that closes the gap.
Tell me which direction you want and I'll iterate inside this same PR.

Coordination

I checked PR #48275 (pluggable CronScheduler). It's backend-only and
explicitly does not touch the model field. No conflict either way on
merge order.

Out of scope

• provider and base_url fields (separate PRs if you want them).
• Public docs (docs/user-guide/features/cron doesn't currently list
  model as a field — happy to do a follow-up docs PR once the UX
  shape is settled).

Tests

There is no unit-test harness for the web dashboard (web/package.json
exposes only dev/build/lint/typecheck), so per the no-new-test-
framework constraint this ships with a manual test note instead.
npm run typecheck and npm run lint pass.

Manual test

1. Open Create Job modal → type moonshotai/kimi-k2.6 in Model →
   create the job.
2. Inspect ~/.hermes/cron/jobs.json — new job has
   "model": "moonshotai/kimi-k2.6".
3. Open Edit Job on the same job — Model field shows the saved value.
4. Change to a different model id, save, re-inspect JSON: updated.
5. Clear the field, save, re-inspect: "model": null.

[tonydwb]

Code Review Summary

Verdict: Approved

Looks Good

• Clean feature addition: Model field in Create/Edit Job modals, wired to the existing per-job model override in CronJobCreate + create_job
• No backend logic changes: Only wires up the existing model kwarg that create_job() already accepted
• Correct type updates: model on CronJobCreate, CronJob interface, create/update payload types
• i18n strings added: modelOptional and modelPlaceholder following existing patterns
• No debug artifacts or secrets

Minor Note

• Frontend accepts any string as model; invalid model names would fail silently at cron run time rather than at job creation. This is acceptable for free-text UX and consistent with the backend accepting arbitrary strings. A validation dropdown (which the author already raised as an option) could improve this later.

---

Reviewed by Hermes Agent

[nujovich]

Superseded by #53551 (merged 2026-06-27), which exposes the per-job model override in the cron Create/Edit modals via a profile-scoped dropdown, plus the rest of the execution fields and the #44585 update-time drift re-snapshot. Rebased onto current main, nothing functional remains here. Closing.