feat(agent-actions): review-request nagging cooldown — throttle or close on repeated review pings

[JSONbored]

Parent: #1936
Related: #2270 (same anti-abuse spirit — capping the pressure one contributor can create — but this
caps repeated review-request nagging via comments/mentions, not open-item count)

Motivation

Contributors who repeatedly comment asking for a review, or ping the maintainer directly, create
disproportionate notification and triage pressure — the same problem class #2270 addresses for raw
PR/issue volume, but via comments instead of new items. Nothing currently throttles or discourages
this; the closest existing surface, @gittensory noise-report (src/services/maintainer-noise.ts),
is read-only and maintainer-pulled, not an enforcement mechanism.

Open design question (resolve before/at implementation, not fixed by this issue)

What counts as a "nag"? Two candidate v1 detectors, both deterministic (matches this codebase's
existing convention — see #1954's explicit "Deterministic; no AI" requirement for eligibility
filters):

1. Explicit @gittensory mention-command repeated past a threshold in a rolling window.
   Cheapest: reuses the existing mention-command parser (src/github/commands.ts /
   maybeProcessGittensoryMentionCommand). Zero false positives — the contributor deliberately
   invoked a command.
2. A plain-language comment that @-mentions the repo owner/admin login
   (ADMIN_GITHUB_LOGINS/authorIsOwner pattern) on a PR, repeated past a threshold. Broader
   coverage of "hey @JSONbored can you look at this," but can't distinguish a genuine question from
   a nag — higher false-positive risk.

Recommendation: ship (1) first since it's unambiguous; leave (2) as an opt-in follow-up knob rather
than baking a fuzzy heuristic into v1.

Requirements

• Config-driven per this project's convention: default disabled, enableable globally (env var)
  or per-repo (.gittensory.yml / repository_settings).
• Two numeric knobs: reviewNagMaxPings (count per rolling window) and reviewNagCooldownDays
  (window length / minimum wait after a ping before another is allowed).
• reviewNagPolicy: "off" | "hold" | "close" — "hold" posts a deterministic "you're on cooldown,
  try again in N days" reply and takes no further action that window; "close" uses the same
  close/comment/closeKind machinery feat(agent-actions): configurable per-contributor open PR/issue cap with auto-close over the limit #2270 introduces, with a new closeKind: "review_nag".
• Owner, admin, and automation-bot authors exempt (existing pattern). Same named-contributor
  whitelist requested for feat(agent-actions): configurable per-contributor open PR/issue cap with auto-close over the limit #2270 (see comment on that issue) applies here too, and should be a single
  shared list, not duplicated per feature.

Deliverables

• Config fields + parser + tests, threaded through the same chain as every other settings field.
• Detector (1) wired into the issue_comment webhook path alongside the existing mention-command
  dispatch in src/queue/processors.ts.
• Counting: reuse the audit_events ledger (recordAuditEvent/hasRecentAuditEvent in
  src/db/repositories.ts) — log a github_app.review_nag_detected event per matched ping. Needs a
  new count-in-window helper alongside the existing boolean hasRecentAuditEvent, since this needs
  "how many in the last N days," not just "any."
• "hold" reply comment template (deterministic, static).
• "close" path: new closeKind: "review_nag" alongside "contributor_cap" (feat(agent-actions): configurable per-contributor open PR/issue cap with auto-close over the limit #2270),
  "blacklist", "linked-issue-hard-rule", "heuristic" in src/settings/agent-actions.ts.
• Docs.

Acceptance criteria

• A repo with this disabled (the default) sees zero behavior change.
• Enabled with policy: "hold": the (N+1)th @gittensory ping within the cooldown window gets a
  deterministic cooldown reply and no other action is taken.
• Enabled with policy: "close": the PR/issue closes with a clear, deterministic reason.
• Owner/admin/bot/whitelisted authors are never throttled or closed by this mechanism.

Expected outcome

A maintainer can choose between a soft nudge (hold) and a hard stop (close) for review-request
spam, symmetric with #2270's blacklist-style deterministic close for PR/issue volume.

[linear-code]

JSO-2466