in-mem maintenance: Delete in-mem v1 after in-mem v2 lands.

[harsha-simhadri]

In-memory providers are in diskann-providers/src/model/graph/provider/async_/inmem. Move them up to diskann-inmem crate.
Move traits and utilities in diskann-providers/src/model/graph/provider/async_/common.rs that are used solely by the in-mem providers to the inmem crate.
If you encounter further Rust orphan rule violations, list all the violations.

Mark is in the process of authoring an in-mem v2 replacement for our current in-mem implementation. Following it landing, the original in-mem implementation will need to be removed.

[JordanMaples]

I had copilot take a look at this. I'm not familiar enough with the architecture to voice whether or not it is fully accurate. Either way, I worry that the scope of this needed work is too large for the scope of #899. Thoughts @harsha-simhadri

Summary

We can cleanly extract the in-memory provider into diskann-inmem if we scope it to the full-precision path and accept that
diskann-providers will depend on diskann-inmem (not the other way around). The quantized providers (product.rs, spherical.rs,
scalar.rs) stay in diskann-providers because they depend on FixedChunkPQTable and the PQ/distance infrastructure.

Dependency direction

 diskann (core traits: Accessor, SearchStrategy, etc.)
    ↑
 diskann-inmem (base types + traits + full-precision provider)
    ↑
 diskann-providers (storage traits, quantized providers, bf_tree)
    ↑
 diskann-disk, diskann-benchmark

What moves to diskann-inmem

From async_/common.rs (types + traits used solely or primarily by inmem):

 - Types: StartPoints, VectorGuard, AlignedMemoryVectorStore, PrefetchCacheLineLevel, NoStore, NoDeletes, TableBasedDeletes,
FullPrecision, Quantized, Hybrid, Unseeded, Panics, TestCallCount
 - Traits: SetElementHelper, CreateVectorStore, CreateDeleteProvider, VectorStore

From async_/ sibling modules:

 - fast_memory_vector_provider.rs — FastMemoryVectorProviderAsync
 - simple_neighbor_provider.rs — SimpleNeighborProviderAsync
 - table_delete_provider.rs — TableDeleteProviderAsync
 - postprocess.rs — DeletionCheck, AsDeletionCheck, RemoveDeletedIdsAndCopy

From async_/inmem/:

 - provider.rs — DefaultProvider, DefaultProviderParameters
 - full_precision.rs — FullPrecisionProvider, FullPrecisionStore, CreateFullPrecision, FullAccessor
 - test.rs — test utilities

What stays in diskann-providers

 - fast_memory_quant_vector_provider.rs — stores Arc<FixedChunkPQTable>, deeply tied to PQ infra
 - inmem/product.rs — DefaultQuant, implements strategies using FixedChunkPQTable
 - inmem/scalar.rs — SQStore, WithBits
 - inmem/spherical.rs — SphericalStore
 - bf_tree/ — separate provider, uses shared types from diskann-inmem as a dependency
 - storage/api.rs — SaveWith, LoadWith traits (used by bf_tree, disk index, etc.)

Orphan rule resolution

The key insight: if VectorStore, CreateVectorStore, SetElementHelper, CreateDeleteProvider move to diskann-inmem, then:

 - ✅ diskann-inmem can impl SetElementHelper for FastMemoryVectorProviderAsync — both local
 - ✅ diskann-providers can impl VectorStore for SQStore — type is local, trait is from dependency
 - ✅ diskann-providers can impl CreateVectorStore for FixedChunkPQTable — type is local

Remaining glue impls that stay in diskann-providers

Two LoadWith impls must stay because LoadWith stays in diskann-providers:

 impl LoadWith<usize> for NoDeletes { ... }        // trait: diskann-providers, type: diskann-inmem
 impl LoadWith<usize> for TableDeleteProviderAsync { ... }  // same

This is legal — LoadWith is local to diskann-providers, and Rust allows implementing a local trait for a foreign type. These are
small glue impls (10 lines each) that bridge the two crates.

Similarly, SaveWith/LoadWith impls for FastMemoryVectorProviderAsync and SimpleNeighborProviderAsync would stay in
diskann-providers since the traits are defined there.

What this doesn't solve

diskann_async.rs (the public constructor API) and index_storage.rs currently live in diskann-providers and reference inmem types
heavily. Options:

 1. Move them to diskann-inmem (cleaner, but diskann-providers tests reference them)
 2. Keep them in diskann-providers, importing from diskann-inmem (simpler)

Open question

Should the quantized inmem providers (product.rs, scalar.rs, spherical.rs) eventually follow? That would require also extracting
FixedChunkPQTable and the PQ distance infrastructure, which is a significantly larger effort.

I had copilot rubberduck the proposal and it came up with these blocking issues, which Mark already summarized in 899.

3 blocking issues:

 1. Strategy marker types can't move — FullPrecision, Quantized, Hybrid, Panics are used by quantized/bf_tree
providers to impl diskann::SearchStrategy for FullPrecision etc. If those types move to diskann-inmem, those
impls become impl ForeignTrait for ForeignType in diskann-providers — orphan violation.
 2. Inherent methods on moved types — FastMemoryVectorProviderAsync::load_from_bin/save_to_bin and
SimpleNeighborProviderAsync::load_direct/save_direct are inherent methods that reference storage internals. You
can't add inherent methods to a type from a downstream crate.
 3. postprocess.rs must stay — its pub(crate) traits (DeletionCheck, AsDeletionCheck) are used by quantized
providers and bf_tree. Moving it means making them public or breaking consumers.

Also: TableDeleteProviderAsync's to_bytes/from_bytes are pub(crate) called by bf_tree — same inherent method
problem.

The clean cut is narrower than the proposal suggested. We'd need to either:

 - Split common.rs (move storage helpers, keep strategy markers)
 - Convert inherent load/save methods to free functions or adapter traits before moving