fix(pg-pkg): give each client its own client_version budget

[dobby-coder]

Closes #388.

postguard_clients kept one process-wide set of seen client_version values, capped at 64 and shared by every client. That budget does not cover the fleet: @e4a/pg-js has published 55 versions and E4A.PostGuard 9, which is 64 between those two SDKs before either add-in or the CLI appears. A busy deployment fills the set from live traffic and then reports every later real release as other until the process restarts, and other is only alertable while nothing legitimate lands there.

This was decided on #384 and asked for in a comment there, but that PR merged as written.

What changed

All of it in pg-pkg/src/middleware/metrics.rs.

• SEEN_CLIENT_VERSIONS is now a HashMap<String, HashSet<String>>: one set per client, still 64 each.
• The map is keyed on the post-allowlist client value, which is a closed set of 8 (pg-js, pg-dotnet, pg4ol, pg4tb, cli, pg-cli, unknown, other), so the worst case is bounded at 8 x 64. Keying it on the raw header field would hand out a fresh 64-slot budget for every client name an attacker invents.
• client_version_label takes that allowlisted value as its first argument, so collect_metrics computes allowlisted(client, KNOWN_CLIENTS) before it builds the label array rather than inside it.
• unknown and other as client_version values still consume no slot, in any bucket. A request whose client resolves to other or unknown spends that bucket like any other.
• The doc comment on the cap now gives the per-client reasoning instead of citing the @e4a/pg-js version count as headroom.

Untouched: the host/client allowlists and their contents, the unknown/other semantics, the shape gate on client_version, the five labels, server.rs, util.rs, cryptify/src/metrics.rs, COMPATIBILITY.md, .github/workflows/.

Tests

Both in the existing test_get_metrics module, driving the real actix app as its neighbours do.

• test_client_version_cap_holds, rewritten: 70 distinct well-shaped versions for one client, then that client's distinct client_version values read off the exposition text are 64 plus other.
• test_a_full_client_does_not_spend_another_clients_budget, new: fill pg-js's bucket to 64, send a fresh well-shaped version as pg-dotnet, assert it is emitted exactly. Same host, path and status on both, so the client is the only dimension that differs.

Test 1 passes under both designs, so test 2 is the only thing that distinguishes them. Reverting the map to a single shared set locally, keeping both tests:

test middleware::metrics::tests::test_client_version_cap_holds ... ok
test middleware::metrics::tests::test_a_full_client_does_not_spend_another_clients_budget ... FAILED

assertion `left == right` failed
  left: {"other"}
 right: {"0.6.0"}

Restored afterwards; the branch holds the map.

Acceptance check

cargo test -p pg-pkg                     # 71 + 3 + 2 + 5 passed, 0 failed
cargo clippy -p pg-pkg -- -D warnings    # clean
cargo fmt -p pg-pkg -- --check           # clean

Reviewed by dobby: the code-comments rule (clean) plus a correctness pass over the whole diff, which raised 2 non-blocking findings, both fixed in bdd2305 — the per-bucket caveat restored to the cap's doc comment, and a regression test added for the budget-key choice (red under the raw-key mutation the rest of the suite passes) — cargo test green across the workspace (pg-pkg 72/3/2/5, 0 failures), cargo clippy -- -D warnings and cargo fmt --check clean — approve.