Darling: the store gains a collector run time table, and the shared run-time rules (part of #4938)

[erikdarlingdata]

Part of #4938.

Why

A collector that runs once a day, such as the index object statistics read, starts whenever the Darling service happened to start. Its load can land in the busiest hour of the monitored server. #4938 gives such a collector an optional run time: a quiet hour the operator picks.

This PR lays the groundwork only. It adds the table that stores the time, and the rules every part of the product will share when it reads, writes or applies one. The worker, the viewer, the CLI, MCP and Lite then cannot each invent their own.

The run time lives in a table of its own, not a column on the schedules table. The viewer's schedule Save deletes a scope's rows in config.config_collector_schedules and inserts them again with a fixed column list (version 3.9.0 ships the same Save). The connect check refuses only an older store, so every released viewer connects to a version 160 store. A column on the schedules table would be set back to NULL by each of their Saves, and a server's -1 would become NULL, so that server would take the fleet's run time. Released viewers cannot be changed, so the run time sits where their Save never writes.

What changes

• Store version 160 (V160) creates config.config_collector_run_times. One row per collector, fleet-wide when server_id is NULL: collector_name, and run_at_minute, a smallint of minutes after midnight on the monitored server's own clock, 0 to 1439. A -1 means "no fixed time on this server". It stops a fleet-wide time, the way an empty array stops a fleet-wide database scope, so a CHECK allows -1 on a server row only. The same two partial unique indexes as the schedules table keep one fleet row and one server row per collector. No row means no run time, so every install that never sets one runs exactly as before. Every statement is IF NOT EXISTS or a drop and create, so a second run changes nothing. It sits on top of the install id's final shape (V159) and does not touch that table or the schedules table. The plan's migration 158 ships as 160.
• A write to the table bumps the reload counter, with the same statement-level trigger the schedules table has, so a running service reloads the run times.
• Server removal. Nothing deletes a removed server's schedule rows, and the table has no foreign key: removing a server deletes its definition only (ViewerDataService.MonitoredServers.cs line 98 and DarlingMcpServerAdminTools.cs line 390). The run-time table matches that: no foreign key, no cleanup.
• Grants. No grant or role list names the schedules table. Provisioning grants the whole config schema (GRANT ... ON ALL TABLES IN SCHEMA config, and default privileges for new tables), so the new table has the same read and write rights with no change.
• The shared run-time rules (CollectorRunTime, next to CollectorCadence). A run time is a 24-hour HH:MM time. It applies only to a collector whose interval is a whole number of days (an on-load collector counts as daily). The slot is taken on the monitored server's own clock. Each server gets a fixed offset of up to one hour, so a fleet does not start together. A run can start up to one hour after its slot. The messages every editor will show are shared too. CadencePhaseOffset moved from the Darling worker into CollectorCadence so these rules can use it. The worker forwards to it, with the values unchanged.
• The service reads the table and resolves it. The schedule read is back to its original columns. A second read takes the run times, and each is carried onto the schedule row for the same scope and collector. A run time with no schedule row gets an entry that sets nothing else (its enabled state is now nullable there, so it cannot switch a collector on or off). ResolveSchedule layers the run time like the other columns: the server row, then the fleet row, then none. It treats -1 as none. It drops a run time whose effective interval is not a whole number of days. The service logs one warning for each such run time each time the schedules load, not each sweep.
• A store at version 159 has no run-time table. The read answers "no run times", with no error and no warning (one debug line at most), and the rest of the load goes on.
• A stored value the CHECK would refuse (a store whose CHECK was dropped by hand) resolves to none, and the load now warns once, naming the collector, the scope and the value. Before, it was dropped without a word.
• The viewer's store version check asks for the table by name. A store the service has not yet migrated to 160 is reported as behind. The viewer's schedule Save is unchanged.
• A schedule defaults comment said the PostgreSQL index bloat collector reads every page of an index. It now says the collector estimates from the catalog (Index bloat estimate arm (pg_stats-based): write the estimator #2561 measured, with the pg_read_all_data grant as its precondition #3234).

Not in this PR

Nothing schedules by the run time yet. The worker's due-time logic, the viewer's editor, the CLI, MCP and Lite follow in the next PR. With no run time set (the only state after this PR), every schedule resolves exactly as before.

Test plan

• Build: Darling.Tests (with the service and the viewer), 0 warnings, 0 errors.
• Without a store: 353 tests, 0 failed, 16 live tests skipped. These are the run-time, rung, store version, migration ladder, viewer schema, probe, repo-file adoption, doc-comment, comment-filter, collector coverage, managed roles, schedule SQL, sweep scheduling and provider classes.
• Against a throwaway PostgreSQL cluster with TimescaleDB, the same classes: 323 tests, 0 failed, 0 skipped. The 8 run-time live tests are in it.
• The viewer's schedule Save, run live with its real SQL, leaves every run-time row as it was: for a fleet scope, for a server scope, for a Save that leaves a scope empty, and for the reset of every server's rows. The schedule rows change as the Save says. At the previous head the old pin showed the opposite: the Save set the column to NULL.
• The rung's SQL run twice on one store that holds rows: no error, the same columns, indexes, constraint, trigger and rows. (The old test migrated a store already stamped 160, so the runner skipped the rung and its SQL never ran twice.)
• The table's columns, its CHECK (-2, 1440 and a fleet -1 refused; 0, 1439 and a server -1 taken), both unique indexes and the reload trigger.
• A store at 159 migrates to 160 with an empty table, its schedule row and the schedules table's columns unchanged, and the install id row and table shape unchanged.
• A store without the table loads with no run times, no warning and no error, and a second load works.
• A value outside the CHECK's range logs one warning naming the collector, the scope and the value, live and without a store.
• With the rung body emptied and the new warning switched off, five pins fail (the rung SQL pin, the 159-to-160 upgrade, the two-run test, the warning without a store, the warning live). Restored, they pass.
• The full suite was not run, and neither was every class that reads a changed file.

Notes

• Nothing is left from the five items. The follow-up writes run times to the new table (the viewer's editor, the CLI and MCP), and has to decide what the viewer's reset of a schedule does with a run time. Today no schedule reset or Save touches the table.
• A run time for a removed server stays in the table, as its schedule rows do.

CHANGELOG

No entry in this PR; the release owner adds it under [Unreleased]. Proposed entry:

• Darling's store can hold a run time for each collector schedule ([Set time on Collector Schedules #4938]) - The store gains a collector run-time table (store version 160). It holds minutes after midnight on the monitored server's own clock, with -1 meaning no fixed time on a server, and it is empty until a run time is set, so nothing changes yet. The worker, viewer, CLI, MCP tools and Lite use it in a follow-up.