feat(review): label new PRs using shared accepted-work checks #5259

User Story

As an OpenShell maintainer coordinating contributions and reviews, I need accepted work labeled automatically so maintainers do not have to classify every new PR manually. Contributors rely on label-filtered notification streams in the GitHub app in Slack and other integrations; classification labels should wait until work is accepted to avoid unaccepted-intake noise.

Problem Statement

OpenShell needs a shared definition of accepted work and a reusable deterministic PR check. A closing reference alone lets unrelated contributors claim any accepted issue. Review-readiness already handles newly opened PRs and reviewer routing and should consume the shared check.

Proposed Design

Define accepted work centrally in CONTRIBUTING.md. A PR qualifies if its author is listed in the trusted merged MAINTAINERS.md or has repository WRITE, MAINTAIN, or ADMIN access; otherwise it must close at least one issue in the target repository with state:accepted whose submitter or current assignee is the PR author. Acceptance and the author relationship must hold on the same issue.

Provide an importable library with a pure predicate for supplied facts and a read-only GitHub metadata adapter. Future tools can reuse it without importing a command-line tool or causing label mutations. Lookup errors propagate rather than becoming negative classifications.

Extend the existing review-readiness workflow and helper to add state:accepted when a newly opened PR qualifies. Include drafts and PRs awaiting area/topic classification. Keep reviewer requests limited to ready PRs with an area label. Labeling is additive at creation; later edits and issue or permission changes do not refresh or remove the label.

Keep existing issue-acceptance and merge requirements unchanged. Define when and why area/topic classification waits for acceptance, and have contributor skills refer to the shared definition. Early issue classification and integration filters remain separate in #5261.

Acceptance Criteria

• Define accepted work once in CONTRIBUTING.md and link to it from contributor skills.
• Provide an importable, read-only library for supplied facts and GitHub metadata.
• Extend review-readiness to label qualifying new PRs, including drafts and PRs without classification labels.
• Use GitHub's closing-issue relationships and PR authorship, not arbitrary mentions or the triggering actor.
• Preserve existing reviewer protections, issue-acceptance checks, and maintainer/code-owner approvals.
• Cover qualifying and nonqualifying relationships, pagination, API failures, opening-time labeling, and reviewer integration with offline tests.

Context

Follow-up to #4863; reviewer permission removal was handled in #5257. Related to #4839. Notification filtering and classification at issue creation are discussed in #5261.