[Feature] Scope authored pull-request portfolios to a repository

[morluto]

Motivation

An agent inspecting recent pull requests for one repository cannot scope authored-PR portfolio discovery to that repository.

A real workflow asked for the authenticated user's recently closed pull requests in Tencent-Hunyuan/UniRL and invoked the then-advertised operation with:

{
  "state": "closed",
  "limit": 20,
  "max_requests": 120,
  "updated_after": "2026-06-01T00:00:00Z"
}

The completed job spent the full 20-item bound on pull requests from morluto/jacobian. No Tencent-Hunyuan/UniRL pull request was returned, so the caller had to leave GitContribute and repeat the query with gh pr list --repo Tencent-Hunyuan/UniRL.

The current consolidated contract has the same limitation: github.sync_pull_request_portfolio(selection=authored) accepts state, date, and request bounds, but no repository scope. Its offline counterpart, corpus.list_pull_request_portfolio, can filter by author and state but not repository.

This makes a bounded result depend on unrelated activity across the authenticated user's entire portfolio. Relevant pull requests can be excluded before repository filtering is possible.

Proposed Solution

Allow authored portfolio synchronization and the corresponding offline read to carry an optional repository scope, for example:

{
  "selection": "authored",
  "repository": {
    "owner": "Tencent-Hunyuan",
    "repo": "UniRL"
  },
  "state": "closed",
  "limit": 20
}

When present, the scope should:

• constrain GitHub discovery before applying the item limit;
• be retained in the durable job request, artifact provenance, recovery actions, and typed follow-up;
• constrain the subsequent offline portfolio read;
• validate the repository before job submission; and
• preserve existing incomplete, bounded, and unknown-coverage reporting.

The repository should remain optional so global authored-portfolio workflows continue to work.

The GitHub adapter already supports RepositoryOwner and RepositoryName in AuthoredPullRequestSearchOptions, and contribution preflight already uses that repository-scoped path. This request exposes the same capability through the portfolio producer and reader rather than introducing a second search mechanism.

Alternatives Considered

• Fetch a global portfolio and filter client-side. This fails when unrelated repositories consume the bounded result before the target repository appears.
• Use github.search_threads and manually hydrate matching PRs. This requires the caller to reproduce identity resolution, portfolio health refresh, coverage handling, and the typed handoff that the portfolio workflow already owns.
• Use native gh pr list --repo .... This recovers the immediate task but leaves GitContribute's corpus, health facets, provenance, and recovery workflow behind.
• Use contribution preflight. Preflight is repository-scoped, but it answers whether prospective work corresponds to an existing open contribution. It is not a general recent authored-PR portfolio read.

Impact

This affects the MCP portfolio contract, authored discovery plumbing, corpus portfolio query, job follow-up/recovery arguments, and their tests.

Observable success criteria:

1. Repository-scoped authored discovery includes a repo:owner/name qualifier before the item limit is applied.
2. A user with newer activity in another repository still receives the requested repository's matching PRs.
3. The job's typed follow-up reads only the same repository, author, and state that were synchronized.
4. Global authored discovery remains unchanged when no repository is supplied.
5. Corpus reads remain offline; GitHub access remains an explicit bounded synchronization capability.

Related but not duplicate: #252 added repository-scoped authored-PR discovery to contribution preflight. This issue extends that scope to portfolio synchronization and offline portfolio reads.

[morluto]

Fixed by #278 (405aac5). Authored portfolio synchronization now accepts an optional repository scope and applies it to GitHub discovery before the item limit. The same scope is preserved in offline portfolio reads, pagination recovery, and the completed job's typed follow-up; regression coverage includes newer unrelated activity consuming the unscoped bound.