catalog: console cluster utilization indexes

[leedqin]

Motivation

Adds maintained, cluster_id-indexed views on mz_catalog_server that back the Console's cluster-detail replica-utilization charts. A per-cluster read becomes a point-lookup on the index instead of an ad-hoc query that recomputes the whole fleet's rollup and only filters to the viewed cluster at the end, so its cost no longer scales with deployment size on the single shared catalog-server replica.

Fixes: CNS-104

Views

mz_console_cluster_utilization_overview: 14 days, 1-hour buckets.
mz_console_cluster_utilization_overview_24h: 24 hours, 5-minute buckets.
mz_console_cluster_utilization_overview_3h: last 3 hours, un-binned.
The two binned views share one SQL body. The 3h view is un-binned: it returns raw per-(replica, sample) rows and the Console bins client-side, instead of a server-side five-pass top-k. That keeps the live-tier arrangement small and lets the Console SUBSCRIBE to it. replica_history is deduped to one row per replica so the (replica_id, occurred_at) key the SUBSCRIBE upserts on stays unique even if a replica ever had two sizes in history.

The per-timeframe views are cherry-picked from #37307.

Tests

Regenerated catalog_server_explain.slt, mz_catalog_server_index_accounting.slt, autogenerated/mz_internal.slt, oid.slt, and information_schema_tables.slt, and updated catalog.td, explain-analyze.td, and indexes.td. sqllogictest and the CI system-parameter defaults force-enable the gated index so the catalog-server snapshots cover it even though it ships off.

[ggevay]

For turning on a feature flag in CI (e.g. in SLT), we usually add it to get_minimal_system_parameters and get_variable_system_parameters. Is there a reason for making this one a special case by turning it on here in sqllogictest.rs?

(Btw. I'm thinking I'll create a "feature flags" skill, because my Claude also often gets confused about how feature flags work.)

[ggevay]

Would be good to mention in the doc comment that this takes effect only at an envd restart.

[ggevay]

Also, I think we don't have a precedent for feature flagging the existence of a builtin object. My Claude tells me this should work, but to be sure, could you please add a test that tries it what happens when this flag is turned on and off, and envd is restarted?

[ggevay]

To fix the upgrade test failure, this will need a migration for mz_indexes. Claude:

0dt Upgrade Smoke Test failure — missing mz_indexes migration step

The 0dt Upgrade Smoke Test failure is deterministic and caused by this PR (the ReadyToPromote timeout / DB-64 match is just the downstream symptom). The new generation panics at boot in update_fingerprints:

thread 'main' panicked at builtin_schema_migration.rs:1043:
fingerprint mismatch for builtin MaterializedView(mz_indexes ...)

Root cause: mz_indexes is a BuiltinMaterializedView whose SQL is generated by make_mz_indexes, which inlines the entire builtin-index set as a literal VALUES (...) list. Adding the mz_console_cluster_utilization_overview_3h_ind / ..._24h_ind builtins changes that VALUES list, hence mz_indexes's SQL text, hence its fingerprint. Because mz_indexes is a materialized view (durable persist state, not ephemeral like a plain view/index), a fingerprint change requires an explicit migration step. On a release→dev upgrade, plan_migration only selects steps with version > source_version, finds none for mz_indexes, and update_fingerprints panics. It only surfaces in upgrade tests because a fresh boot has no old persisted fingerprint to mismatch against — which is why the unit tests passed.

This is exactly the issue #37137 fixed for mz_cluster_replica_size_internal_ind (SQL-398); CI flagged it as a potential regression of that closed issue.

Fix: add a replacement step for mz_indexes at the current dev version in MIGRATION_STEPS (src/adapter/src/catalog/open/builtin_schema_migration.rs):

// Required because the console cluster-utilization 3h/24h builtin indexes
// were added. make_mz_indexes inlines the builtin-index set as VALUES, so any
// add/remove changes mz_indexes's SQL fingerprint and requires an explicit
// replacement step.
MigrationStep::replacement(
    "26.32.0-dev.0",
    CatalogItemType::MaterializedView,
    MZ_CATALOG_SCHEMA,
    "mz_indexes",
),

26.32.0-dev.0 matches the current version in src/environmentd/Cargo.toml and the existing mz_comments step at that version. Only mz_indexes is affected — the new views aren't inlined into any non-ephemeral MV, so they need no step.