fix(merge-tracker): guard tier-3 fuzzy dedup with req/job numbers - #1525

Summary

Closes #1524.

merge-tracker.mjs's tier-3 duplicate detection (company match + roleFuzzyMatch) had no req/job-number awareness. Two distinct postings at the same company with similarly-worded titles could collapse into a single tracker row whenever a req/job number in the free-text Notes column was the only thing actually distinguishing them — e.g. two L&D-type postings at the same employer with near-identical generic titles, different req numbers (R_1494379 vs R_1488728 in the reported case).

Fix

• Added extractReqNumber(notes) in merge-tracker.mjs, which pulls a req/job/posting number out of a Notes cell.
• Wired it into the tier-3 fuzzy-match block: if both sides of a fuzzy-matched candidate have an extractable number and the numbers differ, the candidate is treated as not a duplicate (falls through to "new entry" / keeps searching). If either side has no extractable number, today's fuzzy-match-only behavior is unchanged.

Req/job-number formats found in use

Grepped this project's own data/applications.md Notes column (not the three examples in the issue alone) to build the extraction regex against real formats rather than guessing:

• R_1488728 (underscore prefix)
• Req 1084, Req #1311, Req PRACT011038, Req SENIO001021 (bare/hash/alphanumeric)
• REQ-056759, REQ-1000049295, REQ-2026-32061 (uppercase, hyphenated)
• Job 202606-116491, Job #31786, Job ID 65136 (bare / hash / two-word "Job ID")
• Posting ID 5340, Posting #114148, Posting 26-36
• JR00124259, JR6497 (no separator)
• Ref R2857957, Ref 2026-45698

extractReqNumber()'s regex covers all of these label prefixes (R_, Req/REQ/Requisition, JR, Job, Job ID, Posting, Posting ID, Ref/Reference) with a required trailing digit so it doesn't accidentally match unrelated words like "Required" or "Reference Program" that merely start with the same letters.

Edge case: number on only one side

The issue doesn't fully spec this. I chose to fall back to existing fuzzy-match behavior (still treat as a duplicate if the fuzzy match says so) — you can't prove a mismatch without both numbers, and the issue is explicit that the fix should only prevent false positives, never introduce new false negatives on cases that already work today.

Tests

Added a self-test block to test-all.mjs (mirroring the existing #751/#912 merge-tracker regression blocks, same temp-fixture pattern) covering:

• (a) same-looking titles, different req numbers → NOT a duplicate, both rows survive
• (b) same-looking titles, same req number → still a duplicate (lower score → skipped, no extra row)
• (c) no req number on either side → existing fuzzy-match behavior unchanged (still deduped/updated)
• (d) req number on only one side → falls back to fuzzy match, still deduped

All example/test data uses invented placeholder companies (Fabrikam, Northwind) — no real company names or personal job-search data.

Test plan

• node test-all.mjs --quick — 1158 passed, 0 failed, 1 warning (pre-existing/expected warnings only — no rate-limit flake observed)
• New req/job-number dedup self-test block passes all 4 cases (a)-(d)
• Manually verified merge-tracker output against a debug fixture before finalizing assertions

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Improved duplicate handling in the tracker so similar entries with different request/job identifiers are no longer incorrectly merged.
  • Existing duplicate detection still works when identifiers match, and behavior now falls back safely when identifiers are missing on one or both sides.
  • Added coverage for key merge scenarios to help prevent regressions.