style: format the whole repo with rustfmt

[zzylol]

One-shot cargo fmt --all. Formatting only — no semantic change.

Why now

main carried 159 rustfmt diffs across 28 files. That meant nobody could run cargo fmt --all without burying their change in unrelated churn — when I tried it while working on #115, a 58-line fix expanded to 918 lines and I had to reset and redo the edits by hand. Every PR since (#116, #117, #119, #121, #122) has had to hand-check, file by file, that it introduced no new violations.

Clearing the baseline once makes cargo fmt usable again.

No rustfmt.toml, so this is stock defaults on rustfmt 1.9.0 (edition 2021).

How I verified it is formatting-only

Not by reading 694 lines of diff. Mechanically: for each of the 28 files, tokenize both versions and compare the token multiset, excluding {, } and , (the three tokens rustfmt is allowed to add or remove).

检查 28 个文件
✅ 所有文件：忽略 {}/, 之后 token 多重集完全一致

So the only changes are whitespace, line wrapping, block-to-expression match arms (=> { expr } → => expr), trailing commas, and use-statement ordering.

An earlier, cruder check — "strip all whitespace and compare" — flagged 26 files. That check was wrong, not the diff: it cannot tolerate rustfmt reordering imports or inserting trailing commas. Worth stating because the first result looked alarming.

Verification

cargo test --workspace      # 380 passed, 0 failed
cargo clippy --all-targets  # clean
cargo fmt --all --check     # clean

PromQL corpus unchanged: docs 48/49, testdata 1512/1823.

Follow-up worth considering

This repo has no test CI (only a "Check PR title" check), so nothing stops the baseline from drifting again. A cargo fmt --all --check job would keep it at zero — and, separately, a cargo test --workspace job would have caught the main-does-not-compile breakage that #113 fixed, where two individually-green PRs conflicted semantically once both landed.

🤖 Generated with Claude Code