The list rebuilds itself on a schedule (#776)

[chchatzop]

Fixes #776. Stacked on #905 (on #904, on #903) - merge those first; all four add at the top of the changelog's Unreleased.

What was missing

Asked by the operator. Nothing rebuilt the list on a timer: !update, the dashboard's Update list and the console's update each run it once, and FUTURE.md's "rebuilt ... on a schedule" meant the operator's own cron - which a novice never sets up, and which ran update_list.py around PAUSE_ON_UPDATE and the in-progress guard.

What changed

• LIST_REBUILD_SCHEDULE, off by default, one of four shapes: daily 04:00, weekly sun 04:00 (full day names too), monthly 1 03:30 (a day the month lacks means its last day), every 12h (every 12 hours too). settings_file.parse_rebuild_schedule(); anything else is refused in coerce() - the one door every value comes through - with the four written out, so a bad value never reaches the worker.
• The worker: commands.ensure_rebuild_schedule_worker(), from oserve.startup() and from every rehash, guarded once in runtime.py - the automatic refresh's own pattern, so setting it on the dashboard starts it live and a rehash never starts a second. It waits a minute (a bot just started connects first), then scheduled_rebuild_tick(), which runs exactly handle_list_update_request(..., authorised=True): PAUSE_ON_UPDATE, the one-scan gate and the atomic publish all apply.
• When it is due. A time-of-day schedule: when the last rebuild is older than the most recent slot - a bot down at 04:00 rebuilds once when it is back; a restart at 23:00 after the 04:00 rebuild does not rebuild again. every Nh: N hours after the last rebuild of any kind. "Last" is the newer of the published list's age and runtime.rebuild_schedule_last_attempt - without the attempt, a rebuild that fails (a folder whose disk is not mounted) would start again every minute; it is reported like a manual failure and tried again at the next slot. A rebuild already running is not doubled. Turning it off idles the loop.
• The two open questions, taken as the issue leaned: every Nh counts manual rebuilds too, and a scheduled rebuild does not announce in the channel (nobody asked for it) - !update itself only ever reports to the debug feed.
• Where it shows: an [INFO] Scheduled list rebuild starting line (a LOG line in the mIRC window), a Rebuild : line in the console's status, and the Tools page under Update list - next ..., due now, or where to set one (read when the view opens, from the same status payload the Run button polls).
• Settings page: a new List rebuild category holding the schedule and moving LIST_UPDATE_TIMEOUT / LIST_UPDATE_STALL_SECONDS beside it - "Your list" was at the sixteen the grouping test allows. A new category id, not a renamed one, so nothing attached to your-list moves. Help in three languages (kept under the tooltip length), sample regenerated, FUTURE.md names the setting, both changelogs.

Test

tests/test_the_list_rebuilds_on_a_schedule.py (25): the parser (the four forms, what people will type, empty = off, every refusal naming the forms, coerce()); when it is due (the issue's restart cases, before the slot, never built, weekly, the month clamp, every Nh from any rebuild, the next slot); the tick against a real list file whose age is set (runs what !update runs and says so, not due, not doubled, a failed rebuild not restarted every minute, retried at the next slot, off); the worker (started once and only with a schedule, waits before its first check, boot and rehash wiring); and the three places it shows. Mutation: dropping the attempt record fails the every-minute test; dropping the in-progress guard fails the doubling test.

Verified

Full suite on the stacked branch: 6470 OK (19 skipped).

🤖 Generated with Claude Code

https://claude.ai/code/session_01AP6LSxkr4n9dMFNSNMogmW

[chchatzop]

Rebased onto the rebased #905 (the chain's former base #903 was superseded by #909). Code byte-for-byte the same commit; both changelog entries re-inserted by hand at the top of Unreleased. Full suite on the branch: 6471 OK.