ci: add stale issue closer workflow

[hln33]

Issue #, if available:
N/A

Description of changes:

• Adds stale issue workflow that closes issues labeled as needs-info after 14 days of no response
• See feat: add stale issue closer workflow aws-durable-execution-ci#26 for implementation and testing details

Testing

• Tested in a forked JS repo to confirm workflow works as intended in a consumer repo
  • Test - manually run workflow closes issue with label hln33/aws-durable-execution-sdk-js#2
  • Test - Scheduled workflow closes issue hln33/aws-durable-execution-sdk-js#3

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Codex AI review

No actionable findings. Residual risk is limited to behavior of the pinned reusable workflow, which is outside this PR diff and only runs after installation on the default branch.

Reviewed commit cca76efce8f16607a0ebf100b54e25dce6604616. Workflow run

[github-actions]

Claude AI review

No actionable findings.

This PR adds a single CI workflow (.github/workflows/stale-issue-closer.yml) that delegates to a reusable workflow in aws/aws-durable-execution-ci. It contains no SDK/Java, serialization, checkpoint-and-replay, concurrency, logging, or plugin changes, so the execution-semantics review criteria do not apply.

The workflow follows the repository's established conventions well:

• Reusable workflow pinned to a full commit SHA (consistent with issue-triage.yml and notify.yml).
• Least-privilege permissions: top-level permissions: {} with job-scoped contents: read + issues: write, which matches what a stale-issue closer needs.
• Provides both a daily schedule trigger and a manual workflow_dispatch.

Residual test risk: The actual closing behavior lives in the externally-referenced reusable workflow (aws/aws-durable-execution-ci/.github/workflows/stale-issue-closer.yml@962e6f1), which cannot be inspected from this repo. Two things depend on that external file and cannot be verified here: (1) whether it needs any secrets — unlike issue-triage.yml/notify.yml, this caller passes none (relying only on the auto-provided GITHUB_TOKEN), and (2) whether issues: write + contents: read is the complete permission set it requires (e.g., if it ever touches PRs it would also need pull-requests: write). The PR notes it was validated against a forked consumer repo, which mitigates this.

Reviewed commit cca76efce8f16607a0ebf100b54e25dce6604616. Workflow run