fix: stop stale bot from auto-closing issues [FaaFyfxR9WAQrL7FcAgEHJvztd8cVMxvjHRS55rw1nwH]

[waterWang]

Fixes #8076

Changes:

• days-before-issue-close: -1 — Issues are marked stale but never auto-closed. Marking is informational; closing is destructive, and it hits hardest on the hardest bugs (consensus races, security issues) that naturally go quiet.
• days-before-stale: 45 (up from 30) — More time before marking stale.
• days-before-pr-stale: 21 (up from 14) and days-before-pr-close: 14 (up from 7) — Longer leash for PRs.
• operations-per-run: 300 (up from 50) — The old limit never drained the queue on a repo this size.
• Exempt labels widened — Added consensus, tracking, operations to exempt-issue-labels.
• Removed close-issue-message — No longer needed since issues are never auto-closed.

[github-actions]

Welcome to RustChain! Thanks for your first pull request.

Before we review, please make sure:

• Non-doc PRs have a BCOS-L1 or BCOS-L2 label
• Doc-only PRs are exempt from BCOS tier labels when they only touch docs/**, *.md, or common image/PDF files
• New code files include an SPDX license header
• You've tested your changes against the live node

Bounty tiers: Micro (1-10 RTC) | Standard (20-50) | Major (75-100) | Critical (100-150)

A maintainer will review your PR soon. Thanks for contributing!

[Scottcjn]

Checked this against the current .github/workflows/stale.yml and against the actions/stale v10 semantics. It does the right thing.

The key line is days-before-close: -1, which disables closing. Because days-before-pr-close: 14 is set explicitly, the PR side still closes and only the issue side falls back to the -1. So the resulting behaviour is:

• Issues: labelled stale after 45 days of inactivity, commented on, never auto-closed.
• PRs: labelled stale after 21 days, closed 14 days later.

That is the shape I would want. Dropping close-issue-message is consistent, since issues no longer close.

Two things I checked that are worth noting:

security was already in exempt-issue-labels on main, so an exempt label was not what failed. Whatever got auto-closed was not carrying the label at the time. That is an argument for the -1 doing the real work here rather than the label list, which is how this PR is built. Adding consensus,tracking,operations is still useful as a second layer.

operations-per-run going 50 to 300 is the one change with a cost. It is six times the GitHub API budget per run, on a repo with a lot of open issues and PRs. It should be fine at a weekly cadence, but if the job starts hitting rate limits that is the first knob to turn back down.

No test impact, this is workflow-only. Looks good to me.