api: reconsider SearchResults flat-field exposure + pub(crate) field accessors (pre-1.0)

[Fieldnote-Echo]

From the pre-release (Perplexity) audit, §9.

SearchResults.{scores,indices} are pub Vec<…>. Kept public deliberately for now: the Python binding moves them out by value for a zero-copy hand-off into numpy; switching to fn scores(&self) -> &[f32] accessors would force a clone or an into_parts()-style consuming API. Documented as intentional in src/lib.rs. Worth revisiting before a 1.0 stability commitment — e.g. an into_parts() consuming accessor that preserves zero-copy while letting the internal representation evolve.

Minor, same theme: RankQuant.{packed,bits} are pub(crate) fields; an audit suggestion is pub(crate) fn packed(&self) -> &[u8] accessors for read-only crate-internal access. Purely internal (no external surface), low priority.

Both are pre-1.0 API-shape decisions, not bugs.

[Fieldnote-Echo]

An external technical review of v0.2.0 (May 2026) adds two angles to this pre-1.0 decision on SearchResults's flat-field exposure:

1. #[non_exhaustive] — the fields are pub deliberately (zero-copy Python hand-off), but if a field is ever added before 1.0, callers that pattern-match (let SearchResults { scores, indices, .. }) break silently. #[non_exhaustive] is the correct signal for a struct whose shape may still change, without removing the pub access the binding depends on. Worth folding into whatever this issue settles on.

2. #[must_use] — the related footgun (a discarded search() result is a silent no-op) is being handled as a separate quick fix on branch chore/external-review-quick-fixes (annotates SearchResults + the top_m_candidates* methods), so it's out of scope here.

This issue stays focused on the field-exposure / accessor design call.