feat(ci): add stale PR reminder workflow

[Krirox]

Add a scheduled GitHub Actions workflow using actions/stale@v9 that checks open PRs for inactivity.

• After 7 days with no push or comment: posts a check-in comment
• After 14 days (7+7): adds a stale label
• Never auto-closes PRs
• Removes stale label when activity resumes
• Exempts PRs labeled pinned or work-in-progress

Closes #163

Summary

This PR introduces a GitHub Actions workflow (.github/workflows/stale.yml) that automatically monitors pull requests for inactivity. It aims to keep the PR queue clean and encourage contributors to follow through by posting a friendly reminder after 7 days of inactivity. It does not automatically close PRs, giving contributors a chance to resume or explicitly abandon their work.

Type of Change

• Bug fix
• New feature
• UI / UX improvement
• Refactor
• Documentation
• Other: CI/CD Automation

Related Issue

Closes #163

What was changed?

• Added a new GitHub Actions workflow file: .github/workflows/stale.yml
• Configured actions/stale@v9 to run daily.
• Set rules to comment on PRs after 7 days of inactivity and label them as stale after another 7 days.
• Disabled auto-closing of PRs and issue processing.
• Configured the workflow to remove the stale label when activity resumes.
• Exempted PRs with pinned or work-in-progress labels.

Screenshots

Checklist

• My code follows the project structure and conventions
• I tested this locally (npm run dev)
• No hardcoded secrets or credentials
• I have updated documentation if needed

[vercel]

Someone is attempting to deploy a commit to the codersogs-3057's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Siddhartha-singh01]

The workflow itself is well-configured @Krirox actions/stale@v9 is the right
choice, exempt-pr-labels for pinned/work-in-progress is a thoughtful touch, and
remove-stale-when-updated: true makes for the right UX (label clears on activity).
workflow_dispatch for manual testing is nice too.

One thing to clarify before merge: the description and the YAML don't quite match.

The description says "After 7 days: comment" and "After 14 days (7+7): label." But
actions/stale@v9 with days-before-stale: 7 does both at the same time at 7
days of inactivity it posts the stale-pr-message AND applies the stale label
together. There's no separate "label later" stage in this config.

So could you either:
(a) update the description to reflect the actual behavior "at 7 days: post
message + apply stale label, never close" (which is what the YAML does), or
(b) update the YAML to actually implement the staggered 7-then-7 behavior (e.g.
one job for the soft check-in comment, another for the label at 14 days)?

Either path is fine just want the description and behavior to agree.

Small nit: the workflow disables issue handling entirely, so issues: write in the
top-level permissions: block isn't needed. Could tighten to just
pull-requests: write for least privilege.

Otherwise this looks good once the description/YAML agree, ready to merge.

[Siddhartha-singh01]

Thanks for picking option (b) @Krirox the description and YAML agree now, and
tightening permissions to just pull-requests: write is the right move.

One thing to fix before merge though: Job 1's stale-pr-label: '' is problematic.
actions/stale@v9 uses that label as the "already-processed" marker without one,
either:

• the GitHub API rejects the empty label name (422) and the job errors per-PR, or
• the action re-fires every day, so contributors get a daily check-in comment
  for days 7-13 until Job 2's stale label finally lands at day 14. That's the
  exact bot-spam UX we'd want to avoid.

One-line fix per job use a hidden marker label for Job 1:

# Job 1 (check-in)
stale-pr-label: stale-warned

# Job 2 (label-stale)  unchanged
stale-pr-label: stale

stale-warned is invisible workflow plumbing Job 1 only fires once per
inactivity window because it now has a marker to dedupe against. Job 2 then layers
the visible stale label at day 14. (If you don't want the warned label to linger
after Job 2 fires, you can also have Job 2 remove it via close-pr-label: stale-warned
or a small follow-up step, but that's optional.)

Once that label fix is in, this is good to merge.

[Siddhartha-singh01]

LGTM !
But check the workflows once