get_store_metrics' inventory is blind to 57% of the store it reports on: continuous aggregates and un-enumerated plain tables never appear, and the total is never reconciled #3582

Summary

get_store_metrics reports the store's object inventory by three kinds — hypertable, dimension, background job — and on the largest production store that inventory accounts for 159 GiB of a 415 GiB database. The other 256 GiB is (a) the twenty continuous-aggregate materializations (~235 GiB), which are hypertables the tool never enumerates because timescaledb_information.hypertables lists them under their internal _materialized_hypertable_N names and the collector's catalog walk keys on collector target tables, and (b) plain tables the walk does not name — collect.query_store_text at 15 GiB (V74 stores statement text inline, by design), query_store_plan_map, the alert log, and siblings. The tool answered "here is the store" for 38% of it, and a growth investigation that trusted the tool first went looking for the missing bytes inside the one object it did measure correctly.

Fix shape

1. Aggregates as first-class inventory rows: enumerate timescaledb_information.continuous_aggregates and size each via its materialization hypertable (hypertable_detailed_size on materialization_hypertable_schema.materialization_hypertable_name), reported under the aggregate's user-facing view name with a new object_kind (e.g. continuous_aggregate), carrying compression_enabled and its retention/compression policy presence — the fields the sibling issue (The continuous aggregates are 235 GiB and none are compressed: the rollups outweigh their 9x-compressed source, and they were never on the compression ladder #3581) needed and had to get by hand.
2. A catch-all row for un-enumerated relations: everything in the database's user schemas not otherwise inventoried, summed, over a size floor, as object_kind = 'other' with a count — so the inventory's total is reconciled against pg_database_size and the tool can state its own coverage ("inventory covers 99.6% of the database; 1.7 GiB in 14 un-enumerated relations"). A reconciliation that does not close is itself a finding.
3. Name the biggest un-enumerated plain tables explicitly where the product knows them (query_store_text, query_store_plan_map, config_alert_log): they are stable, product-owned tables, and the inventory should know them by name rather than lump them.
4. Tool description + get_store_metrics note: state what the inventory covers and the reconciliation figure.

Same family as wave 1's payload-honesty work (#3541): a correct query producing a wrong conclusion because the envelope did not state its coverage.

Evidence: ground-truth pg_class size census across all schemas on the largest store vs the tool's inventory, 14:46Z, reconciled to the byte; bus record 20260918T144642Z.