console: set a cluster's autoscaling policy from the Alter cluster form - #40043

…0044)

### Motivation

Ninth PR in the cluster details redesign stack (#39509), on top of
#40043. The redesign's prototype has a Hydration report tab. This PR
adds the data a Hydration tab needs, built on the hydration history the
database now records. The next PR in the stack, #40074, adds the tab.
Part of [CNS-173](https://linear.app/materializeinc/issue/CNS-173).

### Description

- **History**, read with react-query since the history tables have no
index:
- a cluster's hydration episodes from `mz_replica_hydration_history`,
one row per episode with the highest peaks across its processes. Gated
on 26.43, which records a row per process, and leaves out older rows.
Episodes with no objects stay in: on a replica with nothing to hydrate,
such as one running only sources, they're the record that a boot
finished;
- the cluster's replicas from `mz_cluster_replica_history`, so a dropped
replica (a resize, a burst replica) keeps its name and size. Fetched
again when the cluster's current replicas change, and not kept once
unused, so a set of replicas that comes back, as after a burst replica
is dropped, fetches again. The same cluster's answer stays up meanwhile,
filtered to the window as it moves on;
- an episode's objects from `mz_object_hydration_history`, with catalog
ids through `mz_object_global_ids`. Fetched each minute until they reach
the episode's object count, since the collector can record an episode a
visit before some of its objects;
- the highest CPU sampled during an episode, from
`mz_cluster_replica_metrics_history`.
- **Live state**, in SUBSCRIBE-fed TanStack DB collections:
- whether each user object on each of the cluster's replicas is
hydrated. A lookup on `mz_compute_hydration_times_ind`, on the fast
path;
- each object's state on one replica (waiting for a hydration slot,
working, hydrated), from that replica's
`mz_compute_hydration_times_per_worker` in a session pinned to the
replica. Gated on 26.39. It runs on the replica, not on
`mz_catalog_server`, so the tab mounts it only for a replica that is
hydrating.
- **Model** (`hydrationModel.ts`):
- an episode is a full hydration when it starts within two minutes of
its replica coming online or being created, or covers every object the
cluster had when it finished. The second rule catches a zero-downtime
upgrade's rehydration, which runs while the environment is read-only and
so records no boot. Objects created during an episode raise its
threshold as much as its count, so a burst of new objects isn't full.
Any other episode is additive: it covers objects added to an
already-hydrated replica. The database records no cause, so this is
inferred from status history and the objects' creation times;
- a replica that goes offline before it finishes hydrating, such as an
out-of-memory restart loop, is an unfinished hydration. The history only
records episodes that finish, so these come from status history. An
attempt runs from the replica's previous restart or its creation, not
its last online row, since a zero-downtime upgrade writes that row after
the replica hydrated. An attempt that began before the window is skipped
unless an object was created in the window during it, since the episodes
before the window aren't read. End events within a minute of each other
are one restart, unless the replica came back online between them. An
offline row counts as a restart only after an online one, since a new
replica's pod on Kubernetes records an offline row before it first comes
online. An object created during an attempt starts a hydration of its
own, so the attempt finished only if a hydration finished after the last
such object. The creation times come from the cluster's current objects
and, while a restart in the window reads as finished with those, also
from its indexes and materialized views created in the window and
dropped since, read from `mz_object_history`, so dropping the index
behind an out-of-memory restart doesn't hide it. A dropped object counts
only for the restarts while it existed, since dropping one unfinished
records no finished hydration;
- an episode's objects are split into time waiting for one of the
hydration slots and time working.
- `useObjectCreationTimes` keeps its earlier answer up while the objects
overlap, as after one is created, so a new index doesn't blank what
depends on it.
- `useClusterHydrationData` and `useHydrationDetail` load and derive
what the tab shows. The detail's object timings and CPU sample load and
fail on their own, and the timings don't wait on a catalog that failed.
- **Fix:** `SubscribeManager` starts a clean snapshot when it resends a
subscribe the server ended, as when the subscribe's target replica
restarts. The old run's rows and error used to stay, so a per-replica
subscribe read as failed for as long as it stayed mounted. The held
state stays until the new run updates it, so a statement that fails
every time keeps its error without flickering. Resends of a statement
that keeps failing without a snapshot back off from 1s to 30s, so a
replica-pinned subscribe the user lacks USAGE for isn't resent as fast
as the round trip. The first resend stays immediate. The delay is the
reconnect backoff, now shared as `backoffDelayMs`.
- **Fix:** collection subscribes now keep their session variables across
connection attempts. Each attempt sent the defaults instead, so a
cluster passed to a collection subscribe never reached the server. No
existing caller passed one. Only variables that are set are passed, so
unpinned subscribes keep running on `mz_catalog_server`.
- `types/materialize.d.ts` is regenerated with `yarn gen:types`. Most of
its diff is the generator catching up with the catalog: builtin
materialized views are no longer `Generated<>`, and relations added
since the last run (including the two hydration histories and
`mz_object_global_ids`) appear.

`yarn gen:types` doesn't run against Materialize as is: kysely 0.28's
Postgres introspector calls `pg_get_serial_sequence`, which Materialize
lacks, and lists only tables and views, which leaves out the catalog's
builtin materialized views. The types here were generated with both
patched locally in `node_modules`. Fixing the script is a follow-up.

Cost on `mz_catalog_server`: the episode query and the object query read
storage, scoped to one cluster or replica and a time bound, as the
redesign's status timeline already does. Episodes poll at the history's
60s collection interval. The replica history scans its index, fetched
once per change to the replicas and per mount of the tab. An episode's
objects poll each minute only while the open detail is missing some. The
dropped objects read scans `mz_object_history`'s index, which holds
every object the environment has created: 8.5 ms at 32,000 objects on
v26.47, plus about 0.23 ms per 1,000. It runs only while a restart reads
as finished, and again only when those restarts change. Looking the
window's ids up instead costs about 2 ms plus 60 µs an id and takes
several round trips to find them, so it beats the scan only past roughly
70,000 objects.

The Metrics tab's "Hydrating · N objects" badge counts introspection
dataflows as well as user objects, so for a moment after a replica boots
it can disagree with this PR's per-replica progress.

### Tests

- `hydrationHistory.test.sql.ts`: each builder against shadowed
relations (grouping and peaks per episode, the 26.43 filter, episodes
with no objects, dropped replicas in the window, user objects only,
per-worker states combined into one per object, catalog ids for dropped
objects), and against the real catalog, including a new index's
hydration streamed from a session pinned to the quickstart replica.
- `hydrationModel.test.ts`: full and additive episodes, a zero-downtime
upgrade's rehydration counted as full by the objects it covered, a burst
of new objects that outnumbers the existing ones, out-of-memory restarts
that never finished, a restart merged across processes, restarts after a
finished hydration and on drop, a restart while hydrating an object
created after the replica finished, a restart after the replica came
back online kept apart from the one before it, a crash loop a new object
started on a replica up since before the window, the restarts an object
missing from the creation times could explain, an object dropped since
counted only for the restarts while it existed, an attempt that began
before the window, an upgrade's late online row, a new pod's offline
row, a boot with nothing to hydrate, the latest full hydration by
finish, dropped replicas outside the window, heap limits, and object
spans.
- `useLiveHydration.test.ts`: progress counted per replica from the
stream on `mz_catalog_server`, progress complete at once for a cluster
with no replicas, per-object states read in a session pinned to the
replica, following the replica's new process after its subscribe fails
over a restart, and no subscribe before 26.39.
- `SubscribeManager.test.ts`: a subscribe the server ends and runs again
drops its error and old rows, one that fails every time keeps reporting
its error, and one that fails every time is resent with growing delays.
- `queries.test.ts`: the replica history fetched again when a set of
replicas comes back, an episode's objects fetched until all are
recorded, including on reopening the episode, and the dropped objects
read only once a restart needs them.
- `objectCreationTimes.test.sql.ts`: against the real catalog, the
dropped-objects query returns when the cluster's indexes and
materialized views created since the start and dropped since were
created and dropped, and leaves out ones still there, created before the
start, or of another type.
- `replicaProcessMetrics.test.sql.ts` reads its snapshot through the new
shared `readSubscribeSnapshot` helper.

🤖 Generated with [Claude Code](https://claude.com/claude-code)



<!-- devin-review-badge-begin -->

---

<a
href="https://app.devin.ai/review/materializeinc/materialize/pull/40044"
target="_blank"><picture><source media="(prefers-color-scheme: dark)"
srcset="https://static.devin.ai/assets/gh-devin-review-dark.svg?v=4"><img
src="https://static.devin.ai/assets/gh-devin-review-light.svg?v=4"
alt="Devin Review"></picture></a>
<!-- devin-review-badge-end -->