Bind stable vector handles during planning

[anoop-narang]

Summary

This changes the vector resolver contract from ensure_loaded() to prepare(),
and binds a stable Arc<RegisteredTable> during planning.

Why

Previously the planner and executor could re-resolve the registry entry in
separate steps, which left a handoff gap if the active vector index changed
mid-query.

With this change:

• the planner prepares the loaded table once
• execution uses that exact prepared handle
• in-flight queries keep using the same registered table even if a newer one is loaded later

Changes

• replace async resolver method ensure_loaded() with prepare()
• make prepare() return Arc<RegisteredTable>
• update USearchExecPlanner to bind the prepared table during planning
• remove the execute-time resolver reload path
• update UDTF docs to reflect the new contract

Validation

• cargo test

[claude]

Now that registered is stored directly in SearchParams, the four fields schema, key_col, scalar_kind, and brute_force_threshold are redundant copies of registered.schema, registered.key_col, registered.scalar_kind, and registered.config.brute_force_selectivity_threshold. Since RegisteredTable is immutable after construction there's no correctness risk, but it doubles the storage for these values and means future readers have to wonder whether they might diverge.

Suggestion: remove the four flat fields and access them via params.registered.* at the call sites. The only call site that needs schema independently of registered is USearchExec::new (for PlanProperties) and RecordBatchStreamAdapter::new — both can use params.registered.schema.clone() directly.

[anoop-narang]

Addressed in 85a83a6 — removed the four redundant flat fields from SearchParams and access them via params.registered.* at all call sites.