epic: AMS per-repo contribution-profile discovery (labels, docs, agent-facing eligibility signals)

[JSONbored]

Problem

loopover-miner discover <owner/repo> ranks and enqueues candidate issues purely on its own generic scoring model — it has no awareness of a target repo's actual PR-eligibility rules. On JSONbored's own gate-enabled repos (loopover, metagraphed), a contributor PR must link-close an existing open issue that carries a points-bearing gittensor:* label, is not labeled maintainer-only, and is not assigned to the repo owner — an issue that fails any of those conditions still ranks and gets enqueued by discover today, and a PR opened against it would get auto-closed by the gate on arrival.

Hardcoding loopover's own gittensor:*/maintainer-only convention into AMS would only work for JSONbored's own repos — any other repo AMS targets will have a different (or no) eligibility convention, expressed however that maintainer chose to document it (a CONTRIBUTING.md section, a label description, a PR template checklist, an AGENTS.md/.claude skill file, or nothing explicit at all).

Proposal

AMS should build a generic, per-repo contribution profile by reading whatever signals a target repo actually exposes — label taxonomy (via the GitHub API, including label descriptions), CONTRIBUTING.md, .github/* templates, and any AI-agent-facing docs (AGENTS.md, .claude/skills/**, similar) — and use that profile to filter/deprioritize ineligible candidates in discover, instead of assuming every repo works like loopover's own.

Found during live end-to-end verification of AMS's standalone usage (#6205): running discover against a real repo with a mix of contributor-eligible and maintainer-only issues surfaced this gap directly — nothing in AMS today distinguishes the two.

Deliverables

Tracked via the sub-issues below. Together they should produce:

• A defined ContributionProfile shape (what a profile records, how confident it is, how it's cached).
• A concrete extraction path from real repo signals (labels, docs, agent-facing files) to a profile.
• discover actually consulting the profile to exclude/deprioritize ineligible candidates.
• Documented, deliberately conservative behavior when no profile can be inferred at all.

Boundaries

• This epic doesn't require any change to how loopover's own gate enforces eligibility server-side — it's about AMS's own client-side candidate selection getting smarter before it ever opens a PR, so a contributor (human or AMS) doesn't waste effort on a PR the gate would reject anyway.
• Not scoped to build a UI for reviewing/editing a profile — CLI/library-level only for this epic.

[linear-code]

JSO-4642