fleet(queue): dedupe-key cross-checks only run when the matching identity field is present — a packet whose identity arrives via a different field validates with a dedupe key naming a different issue/PR/set

Summary

validate_packet in pkgs/fleet/crates/fleet-queue/src/validate.rs cross-checks the packet's dedupe_key against the payload identity — but every family check in dedupe_errors (validate.rs:327) is conditional on the matching identity field being present:

• fix/triage (validate.rs:379-388): the key's issue number is compared only if let Some(ino) = issue_no — a packet whose identity is a prs list (or a pre-filing source) is never compared.
• pr (validate.rs:389-396): the key's PR number is checked only if !pr_numbers.is_empty() — a packet whose identity is an issue object is never compared.
• pr-set (validate.rs:397-413): the key's PR list is checked only if !pr_numbers.is_empty().
• set (validate.rs:414-427): the key's origin issue is checked only when the set object happens to carry an origin_issue field — a non-empty set object without one (e.g. {"prs": [605, 620]}, the exact shape fleet-queue(validate): payload identity accepts placeholders — prs:[null], string/absent PR numbers, and set:{} validate with no usable identity #5549's own test treats as a valid set identity) is never compared.

Meanwhile manual_schema_errors accepts any one of four identity shapes (issue.number, a non-empty prs list, a non-empty set object, or a source {pr, finding}), with no rule tying the shape to the dedupe family. So a packet can validate cleanly while its payload describes one piece of work and its dedupe key — the unique identity the queue dedupes on, forwarded verbatim by task_from_packet — names a completely different one.

Evidence (verified this run, origin/main 9e20032)

Probe on the laptop (crate ~/git/fleet/probe-queue-xcheck/probe, built against the real fleet-queue crate from worktree ~/git/fleet/probe-queue-xcheck-wt at origin/main, calling the real validate_packet + task_from_packet):

Controls — the cross-check fires when the matching field is present:

• fix key issue:9999 + issue {number: 9999} → errors=[] (match passes)
• fix key issue:8888 + issue {number: 9999} → errors=["packet.dedupe_key: issue 8888 in key does not match payload.issue.number 9999"]
• pr key pr:222 + prs [{number: 222}] → errors=[]; prs [{number: 111}] → errors=["packet.dedupe_key: PR 222 in key is not in payload.prs [111]"]
• set key set:9999:owed:… + set {origin_issue: 9999} → errors=[]; key set:8888:owed:… → errors=["packet.dedupe_key: origin issue 8888 does not match payload.set.origin_issue 9999"]

Escape cases — mismatched key/identity pairs validate with errors=[] and the mismatched key is forwarded verbatim into the task row (task_from_packet output shown):

• fix key issue:222 + identity prs [{number: 111}] only → errors=[], task_dedupe_key="repo-health:v1:fix:developing-today/code:issue:222"
• triage key issue:222 + identity prs [{number: 111}] only → errors=[] (only warning is the unrelated design-default max_attempts warning), key forwarded verbatim
• pr key pr:222 + identity issue {number: 111} only → errors=[], key forwarded verbatim
• pr-set key 111-222 + identity issue {number: 9999} only → errors=[], key forwarded verbatim
• set key set:9999:owed:… + identity set {"prs": [605, 620]} (no origin_issue) → errors=[], key forwarded verbatim
• fix key issue:777 + identity source {pr: 588, finding: "f"} only → errors=[], key forwarded verbatim
• pr key pr:777 + identity source {pr: 588, finding: "f"} only → errors=[] — the key's PR (777) is not even the source PR (588), and nothing compares them

Why it matters

The dedupe key is the queue's only duplicate-work guard: it is the deterministic identity a task is deduplicated on at enqueue. A packet whose key names issue #222 while its payload works PR #111 (a) blocks a later, correct packet for issue #222 as a "duplicate" of work that was never queued for it, and (b) lets a second packet for PR #111 through under a correct key, double-working the same PR. The #5482/#5510/#5549 line of fixes closed the spelling and shape holes in this same cross-check family (non-canonical numbers, placeholder identities); this is the remaining hole — the check itself is skipped when the identity arrives in a different field than the family expects. Whether the right rule is "each dedupe family requires its matching identity field" or "any identity field present must agree with the key" (with a stated carve-out shape for pre-filing source packets, whose key cannot yet name the unfiled issue) is the triage call; what is not defensible is the current silent pass.

Acceptance criteria

• validate_packet rejects, with a field-named error in the existing style, any packet whose dedupe-key number(s)/origin do not match the payload identity it carries — for all five families (fix, triage, pr, pr-set, set), including when the identity is supplied via a different field than the family names, or explicitly requires the matching identity field per family.
• The pre-filing source {pr, finding} identity has a stated, tested rule (either its pr is cross-checked where the family allows it, or source-identity packets are restricted to a dedupe shape that cannot name a mismatched issue/PR).
• Every real packet shape in the fleet corpus still validates (the fleet-queue(validate): payload identity accepts placeholders — prs:[null], string/absent PR numbers, and set:{} validate with no usable identity #5549 corpus check pattern: real packets already carry matching identities).
• Regression tests cover each escape case above plus the existing matching/mismatching controls; the broker /validate + /enqueue path (which shares validate_packet) rejects the same packets.

Distinct from: #5549 (identity shapes — placeholder prs/set elements; closed), #5510/#5482 (dedupe-key spellings; closed), #6430 (packet string-field types; open, different check), #6423/#6426 (max_attempts/not_before validation; open, different fields).