.github: Run workflows on self-hosted triton runners - #424

Summary

• Run every job in .github/workflows/rebase.yml (features, illumos, macos) and .github/workflows/create-quarterly-feature.yml (create-features) on the self-hosted runners instead of GitHub-hosted ubuntu-latest
• All four jobs now use runs-on: { group: triton, labels: [self-hosted, APP] }
• Add a "Reset workspace left by previous runs" step before actions/checkout in each job

Context

The triton runner group has six self-hosted runners, three in DA3 and three in IAD39. All six carry the APP label, so any job can run on any of them.

GitHub-hosted runners give every job a fresh VM. Self-hosted runners keep the workspace between jobs, and these workflows assume a clean one. git remote add netbsd fails once the remote exists. A run that is cancelled (cancel-in-progress: true) or hits a rebase conflict leaves a rebase in progress, which blocks every later run on that runner.

The new step fixes this. If a .git directory exists, it aborts any rebase or merge in progress, removes the netbsd remote, and deletes .git/modules plus the extra, joyent and wip submodule checkouts. actions/checkout then cleans and resets the tree as usual.

Notes

• Workspace reuse is a deliberate choice and can be revisited. We keep .git between runs rather than wiping the workspace each job. Later runs fetch only what changed instead of recloning the ~1.9 GB repo. Wiping every job, as GitHub-hosted runners effectively do, would be about 8 full clones an hour (~300 GB a day) into our DCs. The trade-off is that correctness depends on the reset step catching all leftover state. If that proves fragile, switch to wiping the workspace at the start of each job.
• Not tested before merge. The first scheduled run after merge is the test. Watch the first few hourly Rebase branches against NetBSD runs, especially the second run on each runner, since that is the first one to reuse a workspace.
• Runner group access: triton must allow this repo and must have "Allow public repositories" turned on, because pkgsrc is public. I couldn't check this without org admin. If jobs wait in the queue, this is the cause.
• Public repo on self-hosted runners: these workflows only run on schedule and workflow_dispatch, so outside contributors can't trigger them. Do not add pull_request triggers without first requiring approval for outside contributors.
• trunk is force-pushed every hour by the rebase job itself. Merge this promptly, or rebase the branch onto the latest trunk right before merging. Otherwise the PR base will have been rewritten under it. Prefer "Rebase and merge" so no merge commit lands on trunk.
• Capacity: rebase.yml starts 6 features jobs at once, and there are 6 runners, so they fit with no spare.