Add skill staleness reminder workflow

[ams-thakkar]

Description

Adds a scheduled GitHub Actions workflow that reminds the team to verify skills are still current, so skill content doesn't silently drift out of date.

How it works

• A Python script (.github/scripts/check_skill_staleness.py) measures freshness from the last git commit touching each skills/<name>/ directory and flags any skill untouched for >= 60 days. (Git history is a reliable signal; CHANGELOG dates in this repo are inconsistent.)
• The workflow (.github/workflows/skill-staleness-reminder.yml) runs on the 1st of every other month (cron: "0 15 1 */2 *") plus manual dispatch.
• For each stale skill it opens a deduplicated skill-freshness issue (reused across runs; a commit to the skill dir resets the clock) and assigns a random repository maintainer (admin or maintain permission) to triage.

Why assign a maintainer instead of the author
The SKILL.md frontmatter author field is an internal alias, not a GitHub login (e.g. hokang → GitHub user howard-m-k; redshift-support-specialist lists aws-samples). @-mentioning or assigning it would silently notify no one or the wrong account. So the workflow assigns a maintainer to triage and surfaces the listed author as plain text in the issue body for the maintainer to route to.

Type of change

• CI / tooling

Testing

Verified locally:

• Script runs against the repo and flags eks-operation-review (82d) and enrich-with-aws-security-agent (74d) at the 60-day threshold; author parsing handles single and comma-separated values.
• Rendered issue body is correct (no @-mention, author as plain text, clean markdown).
• Dedup logic routes existing→comment, new→create; random maintainer pick spreads across the pool (Python random.choice, no shuf dependency).
• Live collaborator API returns the expected admin/maintain pool.
• Workflow YAML parses; script compiles.

Not yet verified at runtime (and how to close the gap):

• The workflow has not run on a runner end-to-end (the real gh api/gh issue create --assignee calls, cron trigger). Scheduled triggers only fire from the default branch, so this can't be exercised pre-merge via schedule.
• To validate safely, a dry_run input (default true) was added: a manual workflow_dispatch on this branch logs what it would do (detected skills, chosen assignee, create-vs-comment) without creating or commenting on any issues. Recommend running that dry-run before/after merge, then confirming a real run.

Notes

• Also documented the process in CONTRIBUTING.md ("Keeping a Skill Fresh").
• Separately noticed redshift-support-specialist's frontmatter author is aws-samples (org name, not a person) — out of scope here; flagging for that skill's owner.