[chore] Reduce repeated GitHub connector approvals

[ThreeLight2000]

Motivation

GitHub work in this repository can require many separate approval prompts even when the user explicitly requested a scoped batch operation. The prompts cover read-only checks such as labels, CI, and mergeability, and separate connector approvals for each mutation:

• add a comment;
• create a branch;
• create blobs and a tree;
• create a commit;
• update a branch reference;
• create a draft pull request;
• add/remove labels and update PR metadata.

Extending default.rules does not solve this because those rules govern terminal command approvals, while these prompts are external-change approvals from the GitHub connector.

Scope

• Add repository guidance to minimize redundant natural-language confirmations:
  • execute read-only PR, CI, label, and merge-status queries directly;
  • group related GitHub reads when the repository and item are already specified;
  • do not re-confirm each step of an explicitly requested, repository-scoped batch;
  • ask when scope is ambiguous or the operation is destructive, such as deletion, force-push, permission changes, or secrets access.
• Evaluate a repository-scoped on-request / auto_review configuration for GitHub batch work, with an allowlist limited to explicitly requested actions in the named repository, issue, or PR.
• Document the current connector limitation: blob/tree/commit/ref/PR operations are distinct external changes and cannot currently be collapsed by default.rules.
• Identify whether a trusted GitHub batch tool or automation is needed for true single-approval execution.

Acceptance criteria

• Repository guidance clearly distinguishes terminal command approval from GitHub connector external-change approval.
• Read-only GitHub lookups do not require redundant conversational confirmation when scope is explicit.
• Explicit, repository-scoped batch work avoids per-step confirmation where the connector and project policy support it.
• Deletion, force-push, permission changes, secrets access, and unrelated repositories remain explicitly gated.
• The recommended project configuration and its safety boundaries are documented.
• The limitations and any required follow-up for a batch API/automation are recorded.

Verification plan

• Review the resulting AGENTS/configuration changes.
• Run representative read-only checks for a named PR (labels, latest CI, mergeability).
• Run a safe batch scenario that creates or updates only explicitly requested repository metadata and confirm the approval behavior.
• Confirm destructive and out-of-scope operations still require manual approval.