fix(signals): rank contributor opportunities before the per-repo cap

[galuis116]

Summary

buildContributorOpportunities (src/signals/engine.ts) selected the issues to surface per repo by taking the first 5 of an unsorted list (rankable.slice(0, 5), raw DB order), then scoring only those. The list is named rankable but was never ranked before the cap, so issues at index 5+ were dropped before their opportunity score was ever computed.

This discards the ranking the issue-quality producer goes to effort to build: buildIssueQualityReport scores each issue and returns them sorted best-first, but the consumer keyed the report by issue number for per-issue lookups and ignored the ordering. The quality signal therefore only adjusted the score of whichever 5 issues came first, never which 5 were chosen. A "ready", high-fit issue that the system itself ranked #1 was invisible if it happened to be the 6th available issue in DB order. Closes #393.

This is not cosmetic: these opportunities feed buildContributorFit and the contributor decision pack (queue/processors.ts, services/decision-pack.ts), and the global top-25 ranking was drawn from a biased per-repo sample — steering miners toward lower-fit issues while hiding the highest-value work.

Scope

• src/signals/engine.ts — score every eligible (rankable) issue per repo, then keep that repo's top 5 by computed opportunity score (tie-break on issue number, mirroring the producer's order), instead of capping the raw list to 5 before scoring. The existing global sort + top-25 cap are unchanged.
• test/unit/issue-quality.test.ts — fail-on-revert: a "ready" issue sitting 6th in DB order (behind five "hold" issues) must now surface and rank first.

Validation

• npx tsc --noEmit — clean.
• npx vitest run (full suite) — 1066 passed, 1 skipped; no other assertions affected.
• Branch coverage 97.15% (above the 97% gate); engine.ts 98.02% branch.

Safety

• Behavior is unchanged for any repo with <= 5 eligible issues (scoring all then taking top 5 is identical to scoring the same set). The only change is which issues survive the cap when a repo has more than 5 — now the best-scoring ones, as intended.
• No public schema / API surface change; the opportunity object shape, scoring formula, and global ranking are untouched. The no-quality-report path also benefits (it now caps by lane/label fit rather than DB order).

Notes

The fix selects by the consumer's own opportunity score (lane fit + label-history overlap + quality adjustment − queue/bounty penalties), which is the value the pipeline ultimately ranks on, so per-repo selection and global ranking are now consistent.

[JSONbored]

@galuis116 this is good to merge.

A few notes:

• The ranking logic fits the signal layer and does not add a separate review path.
• The unit test gives enough coverage for the new evidence ordering.
• No code changes requested from me.

Validation expected:

• Current green CI is enough.