docs: Explain sizing clusters with hydration history

[maheshwarip]

Motivation

Users need a practical way to choose a cluster size before they know the hydration memory requirements of their workload. The improved hydration visibility project provides historical replica and object-level observations that make a large-first sizing workflow possible.

Project context: https://app.notion.com/p/materialize/Improved-hydration-visibility-3a513f48d37b806cb3a5e7f5b5a9c1e6

Description

• Expand the cluster sizing guidance with a staged, full-workload hydration workflow that starts at a large size and iteratively sizes down.
• Show how to monitor replica lifecycle events and query replica and object hydration history.
• Explain history scope, object-count semantics, sizing headroom, and autoscaling considerations.
• Clarify restart durability in the system catalog reference and link the history relations to the sizing workflow.

User impact

Users can use persisted hydration history to select a cluster size with sufficient memory and hydration headroom, reducing repeated failures caused by starting with an undersized cluster.

Verification

The documented SQL was validated against Materialize Emulator v26.41.0-dev. Both HTML and agent-readable Markdown documentation rendered successfully, and the system catalog reference checks passed.

[maheshwarip]

Closing in favor of #38726