fleet-queue(validate): dedupe keys accept leading-zero spellings (issue:05424) and number 0 in the fix/triage/pr/set families #5510

Bug

fleet-queue packet validation (pkgs/fleet/crates/fleet-queue/src/validate.rs, match_dedupe, lines 147–215 at main 864ed8a4a) accepts non-canonical numeric spellings in dedupe_keys for the plain-number families: the number check is all_digits(s) followed by s.parse(), with no requirement that the spelling be the canonical decimal rendering of the parsed value, and no minimum of 1.

So all of these validate (valid: true) against a payload naming issue/PR/origin 5424:

• repo-health:v1:fix:developing-today/code:issue:05424
• repo-health:v1:fix:developing-today/code:issue:0005424
• repo-health:v1:pr:developing-today/code:pr:05424 (pr_shepherd packet, prs: [{number: 5424}])
• repo-health:v1:set:05424:owed:developing-today/code (pr_shepherd packet, set.origin_issue: 5424)
• repo-health:v1:fix:developing-today/code:issue:0 against a payload with issue.number: 0 — issue/PR numbers start at 1, so 0 names nothing.

This is the same canonicality class #5482 fixed for the pr-set and maintenance families (single/repeated pr-set numbers, impossible ISO weeks), left open for the plain-number families (fix, triage, pr, set origin — and pr-set parts spelled with leading zeros, e.g. 0100-5424, pass the same parse() path).

Why it matters

The dedupe_key is the queue's deduplication identity: the database treats the key string as the identity of a unit of work. …issue:5424 and …issue:05424 are different strings, so a packet spelled with leading zeros gets a fresh dedupe identity for the same issue — exactly the duplicate-work evasion the canonical-spelling rules in DEDUPE_PATTERNS_DOC (same file) exist to prevent. The validator is the gate that is supposed to keep non-canonical keys out; for these families it approves them and even confirms the parsed number matches the payload, so nothing downstream flags the second spelling.

Evidence (verified this run)

Shipped validator (laptop fleet multicall binary at main 864ed8a4a, invoked as repo-queue validate) on packets derived from the known-good packet-5424-fix.json (probe dir on laptop: ~/git/fleet/probe-dedupe-zero):

• control packet (issue:5424): valid: true
• issue:05424, issue:0005424: valid: true
• pr-family pr:05424 and set-family set:05424:owed:…: valid: true
• issue:0 with payload issue.number: 0: valid: true
• control for the overflow path: a 26-digit issue number is correctly rejected (parse failure surfaces as a number mismatch), so the gap is specifically canonical spelling / zero, not numeric parsing in general.

Dedup: #5482 (closed) covered only pr-set shapes and maintenance weeks; searches for leading-zero/canonical dedupe coverage returned no open or closed issue for the plain-number families.

Acceptance criteria

• match_dedupe rejects any numeric component whose spelling is not the canonical decimal rendering of its value (no leading zeros) in the fix, triage, pr, pr-set, and set families.
• Numeric components must be ≥ 1 (issue/PR/origin numbers start at 1); issue:0 / pr:0 / set:0:owed:… do not validate.
• Canonical keys (e.g. issue:5424, pr-set:100-5424, set:5424:owed:…) validate exactly as before.
• Unit tests in validate.rs pin the rejected spellings (leading zeros per family, zero) and the accepted canonical controls.
• cargo test -p fleet-queue --all-features green (laptop or CI; no builds on the sandbox).