doc: update generated developer documentation (#36318)

## Summary

Automated daily refresh of `doc/developer/generated/` to reflect source
code changes.

This PR was generated by the `update-generated-docs` workflow running
`.claude/commands/update-docs.md`.

## Scope

Only files under `doc/developer/generated/` are modified.

## Review checklist

- [ ] No unrelated rewording or restructuring of existing text
- [ ] No changelog language ("now", "added", "previously", etc.)
- [ ] Changes correspond to actual source code changes

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

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: github-actions[bot]

doc/developer/generated/adapter/_crate.md

@@ -1,6 +1,6 @@
 ---
 source: src/adapter/src/lib.rs
-revision: aa7a1afd31
+revision: 9d0a7c3c6f
 ---
 
 # adapter

doc/developer/generated/adapter/catalog/_module.md

@@ -1,6 +1,6 @@
 ---
 source: src/adapter/src/catalog.rs
-revision: a632912d24
+revision: 9d0a7c3c6f
 ---
 
 # adapter::catalog

doc/developer/generated/adapter/catalog/apply.md

@@ -1,6 +1,6 @@
 ---
 source: src/adapter/src/catalog/apply.rs
-revision: a632912d24
+revision: 9d0a7c3c6f
 ---
 
 # adapter::catalog::apply
@@ -10,5 +10,5 @@ Implements the logic for applying `StateUpdate` diffs from the durable catalog s
 An `InProgressRetractions` struct caches denormalized state stripped during retractions so that the corresponding additions can reuse it without rebuilding from scratch.
 The `ApplyState` state machine batches consecutive updates of the same type when beneficial, then delegates to `apply_updates_inner`, which calls per-type `apply_*_update` methods for roles, role auth, databases, schemas, clusters, network policies, items, system configuration, and more.
 After processing retractions that are not replaced by a corresponding addition (i.e., truly dropped items), `apply_updates` calls `drop_optimizer_notices` to clean up any optimizer notices associated with the dropped items and emits the corresponding `mz_notices` retractions.
-`CatalogState` methods defined in this module (`set_optimized_plan`, `set_physical_plan`, `set_dataflow_metainfo`, `drop_optimizer_notices`) mutate the plan and notice fields stored directly on `Index`, `MaterializedView`, and `ContinualTask` catalog items.
+`CatalogState` methods defined in this module (`set_optimized_plan`, `set_physical_plan`, `set_dataflow_metainfo`, `drop_optimizer_notices`) mutate the plan and notice fields stored directly on `Index` and `MaterializedView` catalog items.
 This is the central reconciliation path used both during initial catalog open and when reacting to concurrent remote catalog mutations.

doc/developer/generated/adapter/catalog/builtin_table_updates.md

@@ -1,6 +1,6 @@
 ---
 source: src/adapter/src/catalog/builtin_table_updates.rs
-revision: d45bbaa9b4
+revision: 9d0a7c3c6f
 ---
 
 # adapter::catalog::builtin_table_updates

doc/developer/generated/adapter/catalog/consistency.md

@@ -1,6 +1,6 @@
 ---
 source: src/adapter/src/catalog/consistency.rs
-revision: d37c5be00a
+revision: 9d0a7c3c6f
 ---
 
 # adapter::catalog::consistency

doc/developer/generated/adapter/catalog/open.md

@@ -1,6 +1,6 @@
 ---
 source: src/adapter/src/catalog/open.rs
-revision: a632912d24
+revision: 9d0a7c3c6f
 ---
 
 # adapter::catalog::open

doc/developer/generated/adapter/catalog/open/_module.md

@@ -1,6 +1,6 @@
 ---
 source: src/adapter/src/catalog/open.rs
-revision: a632912d24
+revision: 9d0a7c3c6f
 ---
 
 # adapter::catalog::open

doc/developer/generated/adapter/catalog/open/builtin_schema_migration.md

@@ -1,11 +1,13 @@
 ---
 source: src/adapter/src/catalog/open/builtin_schema_migration.rs
-revision: d45bbaa9b4
+revision: 6aacf14c48
 ---
 
 # adapter::catalog::open::builtin_schema_migration
 
 Implements schema migration for builtin storage collections whose persist shard schemas change between versions.
 Two migration mechanisms are provided: `Mechanism::Evolution` uses persist's schema evolution to evolve a shard in-place (backward-compatible changes only), and `Mechanism::Replacement` creates a new shard (works for all changes but discards data).
 The `MIGRATIONS` list declares per-version migration steps; `Migration::run` applies outstanding steps, coordinating shard creation, schema registration, fingerprint updates, and cleanup across 0dt-compatible read-only and leader environments.
-`CatalogItemType::MaterializedView` is supported alongside `Table`, `Source`, and `ContinualTask` as a valid target for schema migrations, as reflected by entries in the `MIGRATIONS` list that migrate several `mz_catalog` and `mz_internal` materialized views including `mz_databases`, `mz_schemas`, `mz_role_members`, `mz_network_policies`, `mz_network_policy_rules`, `mz_cluster_workload_classes`, `mz_internal_cluster_replicas`, `mz_pending_cluster_replicas`, `mz_materialized_views`, `mz_connections`, and `mz_secrets`.
+`CatalogItemType::MaterializedView` is supported alongside `Table` and `Source` as a valid target for schema migrations, as reflected by entries in the `MIGRATIONS` list that migrate several `mz_catalog` and `mz_internal` materialized views including `mz_databases`, `mz_schemas`, `mz_role_members`, `mz_network_policies`, `mz_network_policy_rules`, `mz_cluster_workload_classes`, `mz_internal_cluster_replicas`, `mz_pending_cluster_replicas`, `mz_materialized_views`, `mz_connections`, and `mz_secrets`.
+When applying replacement migrations, `mz_storage_usage_by_shard` is excluded from data-destroying replacement plans to preserve billing data.
+When the source and target versions differ and the source version is a dev build, `Migration::run` forces evolution-mode migration even without an explicit `force_migration` config, avoiding version-based filter failures in dev environments.

doc/developer/generated/adapter/catalog/state.md

@@ -1,12 +1,12 @@
 ---
 source: src/adapter/src/catalog/state.rs
-revision: 278f65f05f
+revision: 9d0a7c3c6f
 ---
 
 # adapter::catalog::state
 
 Defines `CatalogState`, the in-memory representation of the entire Materialize catalog.
 `CatalogState` holds `imbl::OrdMap` collections for databases, schemas, roles, role auth (`role_auth_by_id`), clusters, network policies, the item namespace (keyed by both `CatalogItemId` and `GlobalId`), source references, temporary schemas per connection, comments, default privileges, system privileges, system configuration, and a `notices_by_dep_id` index mapping each `GlobalId` to the optimizer notices that depend on it; it also implements `SessionCatalog` for SQL name resolution.
 The file also defines `LocalExpressionCache`, a helper used during catalog open and catalog transactions to track which optimizer expressions were found in (or are missing from) the persistent expression cache, avoiding redundant re-optimization.
-When `deserialize_item` re-parses an existing item (e.g. during a RENAME), it preserves the `optimized_plan`, `physical_plan`, and `dataflow_metainfo` fields from the previous `CatalogItem` incarnation via `plan_fields_mut`; these fields are not reconstructable from `create_sql` alone and must be carried over to avoid silently dropping plans for materialized views, indexes, and continual tasks.
+When `deserialize_item` re-parses an existing item (e.g. during a RENAME), it preserves the `optimized_plan`, `physical_plan`, and `dataflow_metainfo` fields from the previous `CatalogItem` incarnation via `plan_fields_mut`; these fields are not reconstructable from `create_sql` alone and must be carried over to avoid silently dropping plans for materialized views and indexes.
 This is the authoritative read-side view of the catalog; mutations go through `catalog::transact` and are applied by `catalog::apply`.

doc/developer/generated/adapter/catalog/timeline.md

@@ -1,6 +1,6 @@
 ---
 source: src/adapter/src/catalog/timeline.rs
-revision: a632912d24
+revision: 9d0a7c3c6f
 ---
 
 # adapter::catalog::timeline