send_snapshot and reset API - #6042

One blocker.

additional comments:

• I think this won't work correctly when restarting from a checkpoint, since we'll end up sending a snapshot on each restart. We can discuss offline how to handle this correctly.
• I don't see any reason to only allow reset for snapshot-and-follow connectors. I suggest that instead of mode we have a Boolean attribute like initial_snapshot, which only controls behavior on startup. Independent of the value of this attribute, we allow reset for all materialized views.
• Does this require any support in the coordinator? (cc @blp)

I didn't review Python and doc parts, since they will likely change if we address the above issues

LGTM

Re-reviewing because the new [adapters] Materialized indexes commit (847+/235-, 23 files) is a substantial new feature added to a previously-approved PR. Two blockers and several smaller concerns.

Blockers

1. Breaking signature change without SQL-compiler update. register_index and register_index_persistent changed key_fields from &[&SqlIdentifier] to &[String]. The Rust test scaffolding is updated, but sql-to-dbsp-compiler/.../ToRustVisitor.java still emits &vec!(&SqlIdentifier::from("field"), ...) (around line 1083) which is Vec<&SqlIdentifier>. After this PR lands, any SQL program with CREATE INDEX will fail to compile the generated Rust. CI will catch this once it runs, but it has to be fixed before merge.

2. The headline optimization isn't wired up to the SQL compiler. Commit message says register_materialized_output_map simultaneously registers a materialized view and an index sharing one integral, and register_materialized_index registers additional indexes. Neither symbol appears anywhere under sql-to-dbsp-compiler/. SQL-emitted programs still call register_materialized_output_zset + register_index separately, which means the integral-sharing optimization doesn't actually kick in for the primary code path. Either wire it up or split this into a follow-up and clearly say so in the commit message.

Smaller concerns (non-blocking)

• SerCursorFlattened (in crates/adapterlib/src/catalog.rs): nine of its SerCursor methods panic. CSV/JSON/Parquet only call the iteration subset, but anyone adding a new output format or reusing the wrapper later will get a runtime panic instead of a compile error. A focused trait (SerCursorIterate?) capturing only the methods these consumers need would make the API safer; alternatively, add unimplemented!() with an explanation rather than panic! so the failure mode is clearer.
• SerCursorFlattened doc: "Doesn't return values in order" should make explicit that output ordering changes from key-sorted to (key-major, val within key) — relevant for any consumer that depended on snapshot determinism.
• The new feature lacks dedicated tests beyond plumbing parameters through existing scaffolds. The integral-sharing optimization in particular should have a test that asserts the same integral is reused across view + index registrations (e.g. by counting integrate operators in the circuit).
• Commit message subject typo: [adapers] in d058d2bb ("Remove reset_status placeholder.").

Prior REQUEST_CHANGES blockers addressed in 6d27256:

• ToRustVisitor.java now emits the new &[String] key format (appendIndexKeys -> "field".to_string()) instead of the stale &vec!(&SqlIdentifier::from(...)).
• Integral-sharing optimization is wired up: register_materialized_output_map_persistent for the first index of a MATERIALIZED VIEW (sharing the integral with the view), register_materialized_index_persistent for additional indexes, and the materialized view's own register_materialized_output_zset_persistent is correctly suppressed in that case.
• CatalogTests.indexTest/indexTest2 exercise both the materialized and non-materialized paths with the expected register_* call counts.

Soft items from prior review still stand (SerCursorFlattened panics on 9 methods, [adapers] subject typo); already noted, not blocking.