perf(vector/search): HNSW reader keeps `vector_ids: Vec<(u64, String)>` alongside `vector_ids_by_field`

[mosuka]

Round-3 perf push sub-issue (tracked under umbrella #536).

[M] HNSW reader keeps vector_ids: Vec<(u64, String)> alongside vector_ids_by_field

• Where: laurus/src/vector/index/hnsw/reader.rs:46,71,560.
• Current behavior: Held as Vec<(u64, String)> (~32 B / entry) duplicated alongside
  the per-field index Arc<[u64]> (perf(vector): cache vector_ids per field at reader load #405). Double storage.
• Why it might be a bottleneck / risk: Memory only; ~320 MB on 10 M-vector indexes
  wasted because all access goes through vector_ids_by_field now.
• Suggested direction: Drop vector_ids: Vec<(u64, String)>; reconstruct on demand
  from vector_ids_by_field (already grouped). Or keep only a Vec<u64> per field with
  the field index implicit.
• Risk / scope: Small.

---

ID: VS-39 — see ~/.claude/tasks/laurus/20260523_perf_round3_audit/task_list.md for the full Round-3 issue list.

[mosuka]

Substantially subsumed by #859 (PR #862): the reader's retained per-record (u64, String) entries are now (u64, u16) pairs (16 bytes inline, zero per-record heap) plus one shared per-segment Arc<[Arc<str>]> dictionary — for legacy v1/v2 segments too (the dictionary is synthesized at load). The residual idea of dropping the Vec entirely has no remaining ceiling worth an issue.