Add persistent scheduler job store for scheduled backups

[CodeLoopdroid]

Description

This PR adds an initial persistent jobs store implementation for scheduled backups as part of the scheduler refactor.

It introduces a new JobModel to persist scheduled backup intent before execution begins, records skipped scheduled jobs with reasons, and links execution results back to the scheduled job record. The goal here is to establish the database-backed foundation for the larger scheduler refactor without trying to solve the full issue in one PR.

This change is intentionally scoped to the scheduled backup path only. It does not yet include the Jobs UI, post-backup child jobs, or full crash recovery and restart reconciliation.

Related Issue

Part of #2360

Motivation and Context

At the moment, EventLogModel only tracks executed jobs, while pending scheduled jobs and pause-related state are kept in memory. That means scheduled intent is lost on restart and skipped scheduled jobs do not leave behind a durable audit trail.

This PR starts solving that problem by storing scheduled backup jobs in the database and tracking their lifecycle from scheduling to execution or skip. It is meant to be a focused first step toward the broader scheduler refactor described in #2360.

How Has This Been Tested?

I tested this change with targeted unit tests covering both the existing scheduler behavior and the new jobs-store lifecycle.

Test command used:

py -3.11 -m pytest tests/unit/test_job_store.py tests/unit/test_scheduler.py -q -p no:cacheprovider`

Test result:

• 39 passed

The tests cover:

• creating persistent scheduled job records
• linking scheduled jobs to execution results
• recording skipped scheduled jobs with reason codes and reason text
• existing scheduler behavior such as next-run calculation and catch-up scheduling

Screenshots (if appropriate):

Not applicable.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have read the CONTRIBUTING guide.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

I provide my contribution under the terms of the license of this repository and I affirm the Developer Certificate of Origin.