Scheduled restore tests do not create a cron trigger

[borg-codex-bot]

Problem

Setting a job's Restore Test policy to scheduled saves the policy and displays
its due state, but does not establish an automatic execution trigger. Without an
existing enabled restore_test entry in config/schedules.json, the application
does not install a Restore Test entry in the root crontab.

The maintainer reported that no Restore Test entry appears in crontab -l.
This was investigated by reviewing current main, commit
3f4058ca4d8a9b947c46467706e4bbd0d4c31de5 (release 2026.09.07.0935).
The missing connection is supported by the code review below; a separate live
Unraid reproduction has not yet been performed by the agent.

User impact: a job can appear configured for scheduled Restore Tests without
being tested automatically. Due-state calculation and overdue reminders do not
start tests. Manual execution remains available.

Reproduction

1. Use a main-format installation without a restore_test entry in
   <data-directory>/config/schedules.json.
2. In Restore Tests, set an enabled job to scheduled mode, choose an interval
   and test level, and save.
3. Confirm that its job JSON contains restore_test_policy.mode = scheduled.
4. Inspect schedules.json and run crontab -l as root on Unraid.
5. The policy save has not created a Restore Test schedule or cron trigger.
   Restarting the application only reapplies saved schedules; it does not
   create the missing entry.

Code evidence

• Policy save
  writes the job metadata only.
• Cron installation
  supports restore_test, but only iterates schedules that already exist.
• Restore Test schedule UI
  contains empty schedule-button and modal functions, with comments stating
  that the schedule icon was removed.
• run_due_notification_reminders() sends reminders; it does not start tests.
• The existing scheduled-run endpoint selects enabled, scheduled, due jobs.
  It needs an execution trigger; selection logic alone is not a timer.

Expected behavior and scope

Restore Test scheduling must provide an effective, understandable automatic
trigger using the existing scheduling and run mechanisms. Preserve job policies,
existing test results, manual starts, and existing configured schedules.

Keep this as a separate bug fix from #486. It must not expand the permanent
job-ID work or resume frozen #447. No scheduler redesign or unrelated UI changes
are requested. Agree the trigger frequency/time and any necessary scheduling
control with the maintainer before implementation; this issue does not authorize
an arbitrary new default time.

Acceptance checks

• Cover an installation with no prior Restore Test cron entry: configuring
  scheduled testing produces the agreed effective automatic trigger.
• Restart/reapply preserves that trigger without duplicate entries and keeps
  unrelated crontab entries intact.
• Existing Restore Test schedules retain their configured execution time.
• Automatic invocation respects job enabled state, scheduled/manual/off policy,
  due state, existing concurrency protection, and startup migration gating.
• Preserve test intervals, levels, validity settings, results, and manual runs.
• Verify the resulting crontab and an automatic due-job invocation on Unraid;
  record the tested Unraid and plugin versions.

Release notes: required, because this restores user-visible automatic testing.