Autovacuum per-run cost from log_autovacuum_min_duration — the health view says whether it ran, not what it cost #3603

get_pg_autovacuum_health answers "is autovacuum keeping up" from pg_stat_user_tables — dead tuples, last-run timestamps, per-table counts (PgAutovacuumStatsCollector). What it cannot answer is what any given run COST: log_autovacuum_min_duration lines carry per-run duration, pages/tuples removed, read/write I/O, and WAL usage, and Darling does not read them. The failure mode this leaves dark is the classic one: autovacuum IS running (health view green) but each run on one hot table takes 40 minutes of I/O that lands exactly in the business peak — invisible until it manifests as everything else being slow.

This is a parser family on the log pipeline (#3601), sibling to the temp-file family: parse the autovacuum/autoanalyze completion lines on both transports into a runs table (server, database, table, start, duration, pages, tuples, I/O, WAL), and surface per-table run history beside the existing health read so "is it keeping up" and "what does it cost when it does" answer from one place. The health read's recommendations get sharper for free — per-table cost history is the missing input for suggesting cost-limit/naptime changes with evidence instead of folklore.