chore: cargo fmt new code in 3472c74 + my test

[doctatortot]

Tiny fmt sweep — cargo fmt --all on top of upstream main. Surfaces two drifts that landed alongside your larger cleanup in 508e9e6:

• 5 long format! chains in api/mod.rs from your percent-encoding test fix (3472c74) — now wrapped to per-line args
• One .iter().find().unwrap() chain in pipeline.rs from the test_rrf_normalize_weak_top_not_inflated test I added in fix(retrieve): unify rrf_normalize on scale-and-clamp #9 — now broken across lines

Pure fmt, no logic touched. cargo fmt -- --check passes after this; CI will actually run the 379 tests instead of bailing at the fmt step.

Worth thinking about: how to prevent future fmt drift

Now that you've done the big cleanup, fmt drift is going to keep biting both of us at the same rate until something enforces it pre-commit. Three options in increasing scope, all easy to add — happy to do whichever one you prefer in a follow-up PR (or nothing if you'd rather just keep an eye on it):

1. Document in CONTRIBUTING.md — "run cargo fmt before committing." Cheapest; relies on discipline.
2. .githooks/pre-commit + a one-line setup note (git config core.hooksPath .githooks). Hook runs cargo fmt --check on staged files; rejects the commit if dirty. Contributors opt in once per clone. Common Rust-project pattern.
3. cargo-husky as a dev-dep — auto-installs the hook on first cargo build. Zero contributor setup, but adds a transitive dev-dep.

Let me know which (if any) and I'll open a follow-up.

🤖 Generated with Claude Code

[doctatortot]

Closing as superseded by #16, which folds this exact fmt fix into the CI-protoc fix so a single merge restores green CI. No content changes.