refactor: always fully refresh materialized views (#4373)

Simplify experimental materialized views to one output-only storage
layout and one full-rebuild refresh implementation.

## Current layout

Local materialized views currently maintain incremental-refresh state
alongside the materialized values:

- an internal `__source_row_id` column for source provenance;
- `mv.definition` plus `mv.incarnation`;
- source version/timestamp, view version, and last-refresh watermarks;
- optional `mv.staging` state for table-function sources; and
- stable-row-ID requirements on the source table.

Refresh classifies source changes, appends or evicts rows when possible,
and falls back to a rebuild for unsupported deltas. Remote
create/refresh also use separate REST mutation paths.

## New layout

An MV is an ordinary Lance backing table containing only:

- the defining query's output columns;
- its current data fragments; and
- `mv.definition`, encoded as a versioned SQL envelope such as
`{"kind":"query","format":1,"query":"SELECT ..."}`.

There is no provenance column, incarnation, source/view watermark,
staging metadata, or stable-row-ID requirement. Local refresh may still
pin a source version for reproducibility, but it always recomputes the
complete result.

Full refresh streams the new result into uncommitted fragments and then
publishes a single transaction that removes every old fragment and
installs the new set. A shared conflict token prevents concurrent
replacements from both committing. This fragment-replacement primitive
is also used by Sophon's SQL worker.

## New remote create workflow

```text
Connection::create_materialized_view(...)
        -> builder renders the defining SELECT
        -> remote Database receives a CreateMaterializedViewRequest
        -> submit CREATE MATERIALIZED VIEW ... AS ... through Flight SQL
        -> retain the SQL Query handle while the Job is running
        -> consume the durable SQL-job result
        -> open the created table and read mv.definition
        -> return MaterializedView
```

Remote refresh similarly submits `REFRESH MATERIALIZED VIEW` through
Flight SQL. Cancelling either wrapper forwards cancellation to the
retained SQL query before aborting the local task, so the server
operation is not silently left running.

## API changes

- remove incremental/no-op modes and the `full` switch;
- remove distributed grouped/partitioned refresh APIs and native
vector-source MV APIs;
- keep full-refresh results across Rust, Python, and TypeScript;
- preserve list/describe/drop as object-management operations while
routing create/refresh mutations through SQL.

The storage contract is experimental and has no compatibility shim;
views using the removed layout must be recreated.

docs/src/python/python.md

@@ -199,33 +199,6 @@ listing a storage directory.
 
 ::: lancedb.materialized_view.MaterializedViewDefinition
 
-::: lancedb.vector_dedup
-
-::: lancedb.materialized_view.VectorDedupSource
-
-For an existing indexed source, declare and materialize a dedup result without
-writing SQL. Creation captures the source version once and waits for the complete
-result; remote connections use the service's MV jobs.
-
-```python
-from lancedb import vector_dedup
-
-view = db.create_materialized_view(
-    "images_clean",
-    vector_dedup("images", column="phash", distance_threshold=4),
-)
-cleaned = view.table
-```
-
-To submit without waiting, call `db.create_materialized_view_async(...)` with the
-same source expression and wait on the returned job. To declare only, pass
-`with_no_data=True`, then use `view.refresh_async().wait()` when ready. Pass
-`dataset_version=...` to `vector_dedup` for an explicit snapshot. The default
-policy retains direct representatives (A-B-C without A-C keeps A and C), preserves
-the source, and materializes its original columns. Only within-segment/partition
-pairs are covered, using the index's distance representation.
-
-
 ## Views
 
 ::: lancedb.view.ViewDescription