Add automated keep-alive workflow for scheduled jobs

[Copilot]

GitHub disables scheduled workflows after 60 days of repository inactivity. This adds automation to prevent that while minimizing noise.

Implementation

• Runs on the 1st of every month
• Uses the same PR repeatedly by reopening and closing it
• Creates one persistent branch with empty commit, reuses the same PR indefinitely
• No human intervention required

Can be manually triggered via workflow_dispatch if needed.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Keep scheduled workflow alive via scheduled trigger</issue_title>
<issue_description>> > Now also runs weekly so we can automatically catch dependency issues, but we should know this:

"In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days."

We could work around that by running:

git commit --allow-empty -m "Empty commit to keep repository alive"
git push

on each scheduled run.

Sure, and that would be pretty straightforward, but I think I'd rather add a separate job to do it like every 59 days than push an extra commit every week

Originally posted by @TimHess in #106 (comment)
</issue_description>

<agent_instructions>What's the best as-automated-as-possible solution here? If it is the proposed secondary job to push an empty commit, it should check if there's been recent activity and run every 50 days so that we are accounting for weekends and vacations</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@bart-vmware A less invasive approach would be to open a pull request and close it immediately.

• Fixes Keep scheduled workflow alive via scheduled trigger #109

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[TimHess]

@copilot I didn't realize opening and closing a PR would be a viable solution here - can it be the same PR (or issue) that's closed/open/modified? If we could edit or open/close the same PR it would be even less of a hassle. Also, this process doesn't appear to require human intervention, so we can run it every 59 days and forget about the buffer window

[Copilot]

@copilot I didn't realize opening and closing a PR would be a viable solution here - can it be the same PR (or issue) that's closed/open/modified? If we could edit or open/close the same PR it would b...

Yes, great suggestions! I've updated the workflow to:

1. Reuse the same PR: Uses a persistent branch (keep-alive-workflow) and the same PR that gets reopened/closed each time. Much cleaner than creating new PRs.

2. Run every ~59 days: Changed from monthly to cron: "0 0 1 */2 *" (every 2 months = ~59-62 days). Since this requires no human intervention, we don't need the extra buffer.

The workflow now:

• Creates one persistent branch and PR on first run
• Every ~59 days: reopens the PR (if closed) then immediately closes it with a timestamp comment
• Zero noise after initial setup

Commit: cfa441d