Boot-time fail-safe for a monthly-partitioned table.

The weekly partition-lifecycle-<table> cron job is what normally keeps the partition horizon ahead of ingestion. This closes the gap when it has not: a silently dead cron daemon, a clock-skewed failover, or a fresh restore of an old backup all leave ingestion facing a table that cannot accept inserts. On every boot this verifies the next months_ahead months exist and, if any are missing, calls auto_manage_partitions_<table> directly.

Start it under the host's supervisor, ahead of anything that writes to the table:

#{id => partitions,
  start => {ergon_partition_boot_check, start_link,
            [#{table => ~"telemetry", months_ahead => 2}]}}

It blocks the supervisor on purpose

The check runs in init/1 rather than in a handle_continue, so the host's supervisor start-up waits for it. That is deliberate and is the whole design: children later in the tree, the ingest pipeline and the endpoint, must not come up against a table that cannot accept inserts. Failing to boot is a better outcome than booting into guaranteed write errors.

For the same reason, if partitions are still missing after remediation it raises rather than logging. At that point something is wrong that a retry will not fix, most likely the manage function not existing at all, and starting anyway would only move the failure somewhere less obvious.

Once the check passes the process has nothing left to do, so it hibernates rather than sitting on its heap for the life of the node.