[Improve] Offer opt-in notifications when required PR checks pass

[roomote-roomote]

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

Related issue

Requested in the linked task discussion; no linked GitHub issue.

Why this PR exists

• A maintainer explicitly invited this PR in the linked issue or discussion
• I am a maintainer / this is internal Roomote work

Fast can offer to follow pending required checks without unsolicited polling or duplicate PR lifecycle notifications.

What changed

• Verify authoritative required-check capability before offering: "Want me to let you know when the required checks pass?" Suppress unavailable offers and revalidate capability on explicit acceptance before scheduling.
• Monitor only with consent: every 10 minutes for 12 runs, pinned to provider/repository/PR/head SHA, quiet on unchanged results, deduplicated against active monitors.
• Require authoritative required-check policy and complete revision-bound results. The built-in PR read alone is insufficient. Never infer success from empty, partial or unknown data or mergeability.
• Stop on success, merged/closed PR, superseded revision, cancellation, capability loss or timeout. Say "Required checks passed", not "ready to merge". Existing failure, review, terminal and task notifications remain authoritative.
• Add five focused prompt-contract regression cases, including pre-offer capability gating and acceptance revalidation. No new infrastructure.

How it was tested

• Initial implementation: 90 tests passed in Fast prompt and wakeup args/parser/schedule suites.
• Review fix: all 32 Fast prompt tests passed; package check-types passed.
• Normal pre-push oxlint, residual lint, fast typechecks and Knip passed for both commits; Knip emitted a non-failing existing configuration hint.
• Browser proof not applicable to this prompt-generation contract. No live model evaluation, schedules or automations were created.

Pre-merge manual testing

1. Without required-check policy/result access, finish a pending-CI PR: expect no monitoring offer. Explicitly request monitoring: expect an honest limitation and no schedule.
2. With authoritative capability, finish a pending-CI PR: expect one offer and no schedule before consent. Decline: no repeated offer. Remove capability before accepting: no schedule.
3. Accept with capability intact: inspect one every 10m x12, only_when_notable monitor pinned to provider/repository/PR/SHA. Repeated acceptance must not duplicate it.
4. Pending occurrences stay quiet; complete required-check success reports once for that SHA and cancels, without merge-ready wording.
5. Separately test a newer SHA, closing a disposable PR, and user cancellation: stop without retargeting or duplicate notifications. Do not merge this implementation PR for testing.
6. Empty/partial/unknown/missing results must not claim success. Capability loss cancels with one explanation; failures remain with existing logic. At 12 unresolved occurrences, report timeout once without renewal. Clean up test monitors.

Checklist

• The PR title follows the repo convention: [Fix], [Feat], [Improve], [Refactor], [Docs], or [Chore] followed by a user-facing description
• This PR is small and scoped to one change
• pnpm lint and pnpm check-types pass locally
• I added tests or included a clear manual validation note above
• I removed secrets, tokens, private keys, and customer data from code, logs, and screenshots
• If this change should appear in the changelog, I ran pnpm changeset

Full root lint/tsc commands and complete test suite were not run; package checks and normal repository pre-push gates passed. No changeset added. Keep in draft for manual testing; do not merge automatically.

[roomote-community]

No code issues found. See task

• The required-check offer is gated on verified capability (packages/cloud-agents/src/server/fast-agent/fast-agent-prompt.ts:354).

_{Reviewed cf0cb04}