fix(agent-actions): apply account-age throttle on issue contributor-cap path

[RealDiligent]

Summary

Completes the issue-path half of the account-age throttle (#2561): repos that configure accountAgeThresholdDays now get the same anti-ban-evasion friction on issues as they already do on PRs.

Problem

#2561 shipped account-age throttling on the PR maintenance path (tighter contributorOpenPrCap + newAccountLabel), but RepositorySettings explicitly documented that the issue-path enforcement did not read accountAgeThresholdDays. A contributor with a fresh account could bypass the tightened cap by opening issues instead of PRs.

Root cause

maybeCloseIssueOverContributorCap used the raw contributorOpenIssueCap without the half-cap adjustment applied on the PR path, and newly opened issues never received the newAccountLabel.

Implementation

• maybeCloseIssueOverContributorCap: resolve account age via getGithubUserCreatedAt; tighten per-repo issue cap to max(1, ceil(cap/2)) for below-threshold authors (fail-open when lookup fails).
• Issue opened webhook: apply newAccountLabel when review_state_label autonomy is auto, mirroring PR-path exemptions (owner/admin/automation-bot skipped).
• types.ts: update doc comment — setting now applies to both PR and issue cap paths.

Install-wide cap (#2562) unchanged — same as PR path.

Testing performed

• npm run typecheck
• account-age throttle (#2561 issue path): tighter cap + label regression
• account-age throttle (#2561 issue path): off by default — no user lookup

Compatibility

• Default unchanged (accountAgeThresholdDays: null).
• No API/schema changes beyond documentation accuracy.

Why this approach

Mirrors the existing, tested PR-path contract line-for-line rather than introducing new policy. Closes a documented enforcement gap with minimal diff and low regression risk.

Candidate comparison (investigation notes)

Also evaluated but deferred:

• Secret-scan gate/enrichment parity drift — high security impact, but active enrichment expansion (feat(enrichment): detect AI-provider and more SaaS/CI credential formats in secret-scan #3172), open false-positive work (fix(review): reduce false positives in the gate's hard-blocking secret scan #3041), and prior closed parity PRs; higher merge contention.
• Cross-line secret gate (fix(enrichment): join adjacent added lines before secret-scan matching to catch cross-line-split secrets #2454) — unmerged branch exists elsewhere.
• Transient lock ownership — merged (fix(selfhost): use ownership tokens for transient PR actuation locks #3050, fix(selfhost): require releaseIfValue when transient cache exposes claim() #3164).

This issue was selected for unique scope, documented intent, and clear production anti-abuse value with a reviewable diff size.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 Gittensory review result - reject/close recommended

_{Review updated: 2026-07-04 19:15:01 UTC}

3 files · 1 AI reviewer · 1 blocker · readiness 80/100 · CI pending · blocked

🛑 Suggested Action - Reject/Close

• Possible leaked secret in the diff (generic_secret_assignment) — Remove the secret from the diff, rotate the exposed credential, then re-run the gate.

Review summary
This change extends the existing account-age throttle to the issue contributor-cap path by tightening the effective per-repo issue cap for below-threshold authors and applying the configured new-account label on opened issues. The visible wiring preserves the default-off behavior, skips owner/admin/automation authors, and leaves install-wide caps unchanged, which matches the PR description. I do not see a reachable correctness defect in the provided diff, but there are a couple of cleanup points around duplicated lookup logic and stale wording.

Nits — 4 non-blocking

• src/queue/processors.ts:5487 duplicates the account-age lookup and exemption logic that `maybeCloseIssueOverContributorCap` now performs, so a fresh-account issue opened with a configured threshold can fetch the same user twice on the same webhook; please factor this through a shared helper or explain why the duplicate API call is acceptable.
• src/types.ts:850 still documents `newAccountLabel` as applying to a below-threshold account's PR even though this PR intentionally extends that label to issues too.
• src/queue/processors.ts:4699 and src/queue/processors.ts:5487 should share a small helper such as `isBelowAccountAgeThreshold(env, installationId, authorLogin, settings)` plus the owner/admin/bot exemption wrapper so the PR and issue paths do not drift again.
• test/unit/queue.test.ts:10192 should add a narrow assertion for the auto-label autonomy gate, e.g. `review_state_label: "manual"` with a below-threshold account still tightening the cap but not posting the `new-account` label.

Why this is blocked

• Possible leaked secret in the diff (generic_secret_assignment) — Remove the secret from the diff, rotate the exposed credential, then re-run the gate.

Signal	Result	Evidence
Code review	❌ 1 blocker	1 reviewer
Linked issue	✅ No-issue rationale	PR body explains why no issue is linked.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	❌ 5/25	Preflight is holding this PR: the review lane is unavailable, so it is not ready for automated review.
Contributor workload	✅ 10/10	Author activity: 124 registered-repo PR(s), 14 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	RealDiligent; Gittensor profile; 124 PR(s), 0 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: RealDiligent
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: Ruby, Svelte, TypeScript, Cuda, JavaScript, Markdown
• Official Gittensor activity: 124 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Await review-lane availability.
• Refresh registry data or choose a registered active repo.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[loopover-orb]

Gittensory is closing this pull request on the maintainer's behalf (Possible leaked secret in the diff (generic_secret_assignment)). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.

[codecov]

Codecov Report

❌ Patch coverage is 81.48148% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.70%. Comparing base (2b484ec) to head (6bfae45).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
src/queue/processors.ts	81.48%	1 Missing and 4 partials ⚠️

❌ Your patch status has failed because the patch coverage (81.48%) is below the target coverage (99.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3179      +/-   ##
==========================================
- Coverage   94.72%   94.70%   -0.02%     
==========================================
  Files         269      269              
  Lines       29609    29635      +26     
  Branches    10803    10814      +11     
==========================================
+ Hits        28046    28067      +21     
- Misses        917      918       +1     
- Partials      646      650       +4     

Files with missing lines	Coverage Δ
src/queue/processors.ts	92.77% <81.48%> (-0.13%)	⬇️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.