Hardcoding an empty list here will forcibly disable quantization for all local Python users (setting `quantize=false` in the schema), even if they explicitly enable it in their collection configuration. This makes it impossible to test or use the feature locally.

Consider defaulting to `vec!["*".to_string()]` for local bindings to allow usage, or exposing this as a configuration parameter.

File: rust/python_bindings/src/bindings.rs
Line: 132

Enabling quantization now unconditionally flips `schema.get_spann_config_mut().quantize` and later forces `SegmentType::QuantizedSpann` (around line 597) whenever the tenant matches. However, we never verify that the active executor actually advertises support for quantized segments – the capability check above (`if !supported_segment_types.contains(Spann) && !supported_segment_types.contains(QuantizedSpann)`) only ensures *one* of those types exists. In environments where the backend only supports plain SPANN (which was fine before this PR), turning on the new knob will push an unsupported `SegmentType::QuantizedSpann` into sysdb, and the executor will fail the collection creation at runtime.

Before toggling `quantize`/selecting `SegmentType::QuantizedSpann`, guard on `supported_segment_types.contains(&SegmentType::QuantizedSpann)` (or return a clear error/fall back to non-quantized SPANN). For example:
```suggestion
        let enable_quantization = self.should_enable_quantization_for_tenant(&tenant_id);
        if enable_quantization && !supported_segment_types.contains(&SegmentType::QuantizedSpann) {
            return Err(CreateCollectionError::SpannNotImplemented);
        }

        if let Some(ref mut schema) = reconciled_schema {
            if let Some(spann_config) = schema.get_spann_config_mut() {
                spann_config.quantize = enable_quantization;
            }
        }
```
This keeps legacy deployments (without quantized SPANN support) from attempting to create unsupported segments while still enabling the feature where it’s available.

File: rust/frontend/src/impls/service_based_frontend.rs
Line: 555

The validation logic here (`if user.quantize || default.quantize`) combined with forcing `quantize: false` (line 1650) creates a critical issue for the read path.

When a collection is created, `ServiceBasedFrontend::create_collection` sets `quantize = true` in the schema and persists it to SysDB. When this collection is later retrieved via `get_collection`, `reconcile_schema_for_read()` calls `reconcile_with_defaults()`, which invokes this merge logic.

1. The validation check will fail because the persisted schema (treated as `user`) has `quantize: true`, causing `get_collection` to return an error.
2. Even if the validation passed, line 1650 forces `quantize: false` in the result, effectively disabling quantization in the loaded schema object, which creates a mismatch with the actual segments.

**Fix:** 
1. Remove the validation from `merge_spann_configs` (or scope it only to user input validation phase).
2. Preserve the `quantize` value from the `user` (source) schema instead of hardcoding `false`.

File: rust/types/src/collection_schema.rs
Line: 1624