feat: edit backup settings on their own page instead of a dialog

[tulayha]

Stacked on #18; GitHub retargets this to develop once that merges.

What

• Backup Settings (the settings form already linked in the sidebar) is now the only place to edit settings. It gets the day-pill schedule editor and the off-site storage status that only the dialog had.
• The Settings button on Backup Control opens that page; the settings dialog and its save_settings endpoint are removed.
• Backup Control reloads when you return to it, so the "Scheduled backups" card reflects what was just saved.

Why

Settings could be edited in two places that behaved differently: the dialog had the good schedule editor, the form had a raw table with comma-separated weekdays. The dialog also kept its own copy of the settings, which went out of sync when it was reopened.

Notes

• The schedule is still stored in the backup_schedule child table, now hidden; the editor reads and writes its rows, so saving, validation and change tracking are the form's own.
• The schedule editor is always shown. The dialog hid it while scheduling was disabled and silently kept the previous schedule on save.
• Times loaded from the database (9:00:00) are padded before they go into the time input, which otherwise showed them empty.
• "Remote Retention (Days)" is relabelled "Off-site Retention (Days)" to match the rest of the screen.
• get_configuration reports only whether each deployment variable is set, never its value, and is System Manager only.

Testing

Tests updated for the form, saving and the new endpoint (CI). Checked by hand on a local v16 bench in light and dark theme: toggling days, adding and removing rows, changing a time, saving, the client-side validation message, the storage status, and Backup Control picking up the saved state on return. Not checked on v15 in a browser.

[tulayha]

🎉 This PR is included in version 0.2.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀