fix(core): prevent os error 33 on Windows by reading usearch index from locked file handle

[webhop123]

Description

Fixes the Windows \ERROR_LOCK_VIOLATION\ (\os error 33) described in #732 that breaks the multi-agent CLI workflow.

Root cause:
The \VectorIndex::load_or_create\ function acquired an exclusive cross-process lock on the .usearch\ file, but then called \std::fs::read(path). On Windows, byte-range locks are enforced at the OS handle level. \std::fs::read\ attempts to open a second handle to the same file and read from the locked region, resulting in an immediate lock violation from the OS.

Solution:
Instead of opening a new handle, the \load_from_file\ method now reads the file contents directly from the already-locked \File\ handle before deserializing.

Changes

• Extracted a \load_from_file(&mut File, &Path)\ method in \crates/uteke-core/src/memory/vector.rs.
• \load_or_create\ now passes its exclusive \lock_file\ directly to \load_from_file, avoiding a second conflicting file handle.

Testing

• Validated via \cargo check\ locally.
• Solves the documented multi-process bug where the second CLI process fails to read an existing store.

Closes #732.

[ajianaz]

Thanks for opening the new PR targeting develop, @webhop123! 👍

Almost there — one CI check is failing:

Check	Status
Build	✅
Check	✅
Clippy	✅
Cora Review	✅
Cargo Audit	✅
Test	✅
Trivy FS Scan	✅
Format	❌

You can fix the formatting by running:

cargo fmt --all

Then commit the changes and push. Once CI is green, we'll get this merged! 🚀