upstream: brute_force serialize/deserialize Rust bindings (cuvs follow-up 1/3)

[jamie8johnson]

Follow-up cuvs contribution #1 of 3 (smallest first — see also the scalar-quantizer and refine issues). Single-feature PR per upstream norms.

What

Wrap brute_force serialize/deserialize in the cuvs Rust crate. The C header (c/include/cuvs/neighbors/brute_force.h) exposes serialize symbols (6 mentions); rust/cuvs/src/brute_force.rs wraps none of them. Pure parity gap — same template as our CAGRA/IVF-SQ serialize work.

Upstream guidelines (digest, from .github/PULL_REQUEST_TEMPLATE.md + observed conventions)

• Unit tests required for all changes (serialize round-trip re-verifying search, mirroring our IVF-SQ test)
• PR description in the template text box; use closing keywords if an upstream issue exists
• Never rebase/force-push after review begins — merge main into the branch for conflicts
• Don't expand scope after review starts
• Maintainers apply labels (improvement/feature request + non-breaking); plain imperative title (e.g. "Add serialize/deserialize to brute_force Rust bindings"); draft PR if not review-ready
• RAPIDS copyright header on changed files, creation-year-to-current range; commit style feat(rust): ... per recent rust PRs
• Branch off main (RAPIDS retired branch-XX.YY)

Etiquette gate

Hold submission until NVIDIA/cuvs#2229 (IVF-SQ) gets first maintainer feedback — incorporate any conventions they request there before opening this one. Implementation can proceed any time in ~/cuvs-contrib (branch rust-brute-force-serialize).

[jamie8johnson]

Upstream PR submitted: NVIDIA/cuvs#2231 (branch rust-brute-force-serialize). Symbols were already bound in cuvs-sys; Rust-side only. Review verdict: ship; path_to_cstring triplication acknowledged in the PR body with a hoist offer. Side discovery: brute_force Index holds a non-owning view whose shape pointer borrows the host ndarray dims — dropping the host array before the index SIGABRTs at Drop; filing upstream as its own issue.