[TheGreatAxios]

Closes CL-11536

Why
Two open pull requests can make the same change, and a reviewer only finds out by chance. Triage now compares each pull request with the ones opened before it on the same base branch and says which one it repeats.

What changed

• New rule no-duplicate: fails when an earlier open pull request on the same base branch (drafts left out) has the same latest commit, the same diff or the same commits, and the comment names it ("has the same changes as fix(tooling): typecheck with plain tsc #12"). The pull request opened first never fails. Another pull request whose diff or commits can't be read is compared on what was read. The rule is unconfirmed past 100 earlier open pull requests, when this pull request's own changes can't be read, or when an earlier pull request's list of changed files can't be read, and it names that pull request.
• New judged rule duplicates-open-pull-request: Triage shortlists up to five earlier open pull requests that share a changed file (lockfiles left out) or two title words of four or more letters (common words left out). The decision model rates each as same change, overlaps or unrelated. A likely same change fails the rule and names that pull request. By default it asks a maintainer, so the verdict is Unsure.
• Reads stay small: one listing per base branch, then one page of changed paths per earlier pull request. The diff hash and commits are read only for pull requests whose paths could match, which is usually none.
• Both hosts' open listing takes a base branch (GitHub through a new typed listOpenPrsInto, Bitbucket Data Center through its at filter). The browser extension answers it from github.com's list filtered on that base.
• Both hosts get a pr_diff_hash tool. It uses the hash the hub's code review takeover already used, now shared as @corbits/common/diff-hash.
• Both rules are off in the recommended policy. This repository's own policy will turn them on in a follow-up, merged once this change is deployed, so the running Triage never reads rule ids it doesn't know.
• New no-model eval bun run eval:duplicates for the shortlist.
• Docs: user manual (rules, onFail defaults, Close), PRODUCT.md, ARCHITECTURE.md (facts step and its read cost), DECISION_MODEL.md, the triage-workflows and policy check READMEs.

Verified

• duplicates.test.ts covers:
  • a same head, a same diff and the same commits
  • later and draft pull requests left out
  • reads limited to pull requests whose paths could match
  • another pull request's unread diff passing; its unread file list, or this pull request's own unread changes, leaving the rule unconfirmed
  • the 100 cap
  • the shortlist order and the judge request
  • both comment lines
• New tests for the base-filtered listing on GitHub and in the extension.
• Affected packages, the extension and the hub's github and code review tests: 976 pass, 2 fail. The 2 failures were policy-check main.test.ts timeouts under load. That file passes alone (6 of 6), as do github-reads and github-tool after the last change (70 of 70).
• No-model evals: hidden-content 187/187 before and after, and the scan eval's output is unchanged. The new shortlist eval passes 8 of 8 cases. It has no before, since the rule is new. The judged question is unmeasured, and DECISION_MODEL says so.
• bun run check, bun run lint and the local policy check pass. The policy check asks about one rule: the change touches 35 files and the limit is 30.

[linear-code]

CL-11536