feat: make Django configs drive backups and scheduling

Treat SQL-backed Django models as the source of truth for pobsync
configuration, exporting runtime YAML only as a compatibility layer for
the existing engine. Add a database-driven scheduler command, Docker
scheduler services, schedule run-state fields, and tests for scheduler,
config export, and retention behavior.

README.md

@@ -145,6 +145,18 @@ Run a backup through Django while still using the existing pobsync engine:
 python3 manage.py run_pobsync_backup <host> --prefix /opt/pobsync --prune
 ```
 
+Export database configs to the runtime YAML files consumed by the current engine:
+
+```
+python3 manage.py export_pobsync_configs --prefix /opt/pobsync
+```
+
+Run due schedules from the database:
+
+```
+python3 manage.py run_pobsync_scheduler --loop --interval 60
+```
+
 ### Docker with SQLite
 
 ```
@@ -157,12 +169,24 @@ This starts Django on:
 
 The container persists `/opt/pobsync` and the SQLite database in Docker volumes.
 
+Run the Django scheduler alongside the web admin:
+
+```
+docker compose up --build web scheduler
+```
+
 ### Docker with MariaDB
 
 ```
 docker compose --profile mariadb up --build web-mariadb
 ```
 
+With the scheduler:
+
+```
+docker compose --profile mariadb up --build web-mariadb scheduler-mariadb
+```
+
 The MariaDB profile is optional. SQLite remains the default because it is enough for a single backup server and keeps deployment simple.
 
 ### Refactor direction
@@ -171,5 +195,7 @@ Recommended next steps:
 
 - Move config reading/writing behind a repository interface that can use YAML or Django models.
 - Record `run-scheduled` results into `BackupRun`.
+- Treat SQL as the source of truth and export YAML only as a compatibility layer for the current engine.
+- Run schedules from Django/Docker instead of writing host cron files.
 - Add a snapshot discovery command that syncs existing snapshot metadata into `SnapshotRecord`.
 - Add tests around retention, scheduling, and config merge before deeper internal reshaping.