Docs: API reference drift around bit widths and file formats

[gabrielemidulla]

While reading the public docs against the current Rust API, I found a few small docs drifts:

• docs/api.md says Python bit_width is in {2, 4}, but the constructors accept {2, 3, 4} and the tests cover 3-bit.
• The file format section still describes an older layout: .tv starts at the 9-byte header and .tvim says version 1. Current io.rs writes TVPI / TVIM magic, version 3, per-vector scales, and the TQ+ trailer.
• The README Rust snippets call TurboQuantIndex::new and IdMapIndex::new without handling the Result.

Why it matters:

These are small docs bugs, but they can confuse new users trying the public API or reading saved index files.

I have a tiny docs-only change ready in my fork:

gabrielemidulla@07b9605

It updates only README.md and docs/api.md.

Validation:

cargo test -p turbovec --doc
2 passed, 0 failed

If this direction looks useful, happy to open the PR. Can I get contributor access for this issue?

[RyanCodrai]

Thank you for raising this issue! Really appreciate it. Will take a look at this ASAP

[RyanCodrai]

Fixed in #102 (merged). All three items you reported are addressed:

• docs/api.md bit_width corrected to {2, 3, 4}.
• File-format section rewritten — .tv now documents the TVPI magic + version 3 + per-vector scales + TQ+ trailer; .tvim corrected to version 3.
• README Rust snippets now handle the Result from new (.unwrap()), matching the crate's doctests.

A follow-up sweep also caught a few more drifts (an inverted filter-operator list in the LlamaIndex docs, a stale SIMD module comment, a wrong side-car extension, and a dead example reference), all included in the same PR. Thanks for the careful, well-scoped report — exactly the kind of issue that's easy to act on.