AMS contribution-profile: exclude candidates assigned to the repo owner in discover

[JSONbored]

Problem

Part of the AMS contribution-profile epic (#6793). #6798 (merged via #7024) wired label-based eligibility filtering into loopover-miner discover, but explicitly scoped out one of the three exclusion rules the epic originally called for: excluding a candidate issue assigned to the target repo's own owner. From #7024's own description:

The issue lists "excluded assignee" as one fail reason, but the candidate objects flowing through discover carry label names and not assignees (opportunity-fanout.js's normalizeIssue drops them)... Threading assignees through the fan-out is a genuine second shared-file change, so this PR scopes filtering to labels... and documents assignee-exclusion as a follow-up rather than half-wiring it.

This issue is that follow-up.

Requirements

• Extend RawCandidateIssue (opportunity-fanout.js) with assignees: string[] — already present in the same GitHub list/search payload discover already fetches (issue.assignees), so this is free (no extra request).
• Extend filterCandidatesByProfiles (contribution-profile-filter.js) with a new exclusion reason (e.g. excluded_assignee) for a candidate assigned to its own repo's owner login.
• Unlike the label-based rules, this check must be structural and always-on — per the schema's own design (ContributionAssigneeRuntimeCheck, contribution-profile.d.ts), assignee-exclusion is deliberately not a profile field; it's derivable from the issue's own assignees at query time, independent of whether the repo's ContributionProfile has a trustworthy eligibility signal. It must NOT be gated behind the existing eligibilityLabels.confidence === "explicit" safe-default check that gates the label rules — it applies regardless of profile confidence.

Test Coverage Requirements

• A candidate assigned to the repo's own owner is excluded, reason excluded_assignee, even when the repo has no ContributionProfile / a low-confidence one (proving it isn't gated behind the label safe-default).
• A candidate assigned to someone other than the repo owner is unaffected.
• Existing label-based exclusion/inclusion behavior from AMS contribution-profile: wire eligibility filtering into discover #6798 is unchanged (regression coverage on the existing contribution-profile-filter.test.ts suite).

Expected Outcome

discover excludes candidates assigned to a repo's own owner unconditionally, closing the one exclusion rule #6798's original scope called for that #7024 didn't implement.

[linear-code]

JSO-4775