feat(query-tracker): validate weighted-mode config and make apply_batch atomic

[Mctursh]

two follow-ups from the #34 review: the weighted-mode config validation, plus the apply_batch transaction fix you agreed to fold in here.

config validation

the weighted priority-mode weights and without-index-compensation-factor are formatted directly into the score SQL (store/prioritization.rs) with nothing validating them. two ways a bad value bites at runtime:

• non-finite (inf/nan from TOML) renders as a bare inf/NaN token that Postgres reads as an unknown column, so every create/evict/regression pass errors out and no index gets created or evicted.
• a negative weight is valid SQL but flips the (1 + w*...) volume factor and inverts the ranking (highest-demand pattern sorts as least valuable).

validated at load instead: the four weights must be finite and >= 0, the compensation factor finite and > 0. two small deserialize_with helpers, the same pattern as the existing deserialize_duration_required on the neighbouring rate-window field. tests cover a valid config loading plus rejection of a negative weight, inf, nan, and a non-positive compensation factor, through the real from_str path.

apply_batch atomicity

apply_batch committed each observation in its own transaction, so a mid-batch database error left the earlier ones committed while the client re-buffered and retried the whole chunk, re-applying that prefix and inflating demand/cost. it's silent: the double-apply lands on the retry, and nothing logs at the point the counters inflate. record_demand now runs against a caller-provided connection and apply_batch wraps the whole batch in one transaction, so a failure rolls everything back and the retry re-applies cleanly, which is what the client's re-buffer already assumes.

one thing that falls out of using a single transaction: it now holds every pattern's row lock until commit, where the per-observation transactions held one at a time. so observations are sorted by pattern_id before the upserts, giving two concurrent batches that share patterns a consistent lock order so they can't deadlock.

defaults are unchanged. fmt and clippy clean. the config validation has unit tests; the apply_batch change is compile and clippy verified, exercising the ingest path end to end needs a live Postgres.