chore(review): address non-blocking review nits from the credibility-gate-farming series

[JSONbored]

Background

The gittensory-orb review on #3513 (and #3575) flagged several non-blocking
"nits" alongside their (already-fixed) blockers:

• src/review/unlinked-issue-match.ts: a Unicode ellipsis in the truncated
  diff marker, inconsistent with this repo's ASCII-source convention.
• src/signals/unlinked-issue-candidates.ts: a duplicate "would" entry in
  STOPWORDS.
• src/signals/unlinked-issue-candidates.ts: basename path-mention matching
  used raw .includes(), so a basename like reader.ts could false-positive
  inside an unrelated, longer filename such as csv-reader.ts.
• src/review/linked-issue-hard-rules.ts: resolveLinkedIssueHasOpenReference
  fanned out one live GitHub fetch per linked issue number with no bound,
  unlike its sibling resolveLinkedIssueHardRule, which already refuses to
  proceed past MAX_LINKED_ISSUE_NUMBERS.
• src/settings/agent-actions.ts: the new stale-disposition-label cleanup
  loop (from fix(review): clear stale disposition labels once the underlying hold resolves #3575) re-scanned the PR's label array per candidate instead of
  precomputing a Set, and had no defensive dedupe if two label settings were
  ever misconfigured to the identical string.

None of these are functional bugs on their own, but they're worth closing out
in one pass while the surrounding code is fresh.

Fix

• ASCII ... (diff truncated) marker.
• Removed the duplicate stopword.
• Basename matching now requires an exact path-like token match (or a longer
  path ending in /basename), not raw substring containment.
• resolveLinkedIssueHasOpenReference now fails open (returns true,
  matching its own stated ambiguity philosophy) rather than fetching, once
  the linked-issue count exceeds MAX_LINKED_ISSUE_NUMBERS.
• The label-cleanup loop now precomputes a lowercase Set of live PR labels
  and dedupes by lowercase label string before emitting a remove action.

[linear-code]

JSO-2821