Owner-only blockers: staging runner meshcore-runner-2 and repository roles

[efiten]

@Kpa-clawbot

Follow-up to #1922, which is closed now that the PR queue is moving again. What is left from it can only be resolved by the repository owner, so it gets its own issue instead of staying buried in that thread.

1. The staging runner meshcore-runner-2 is gone

Deploy Staging runs on [self-hosted, meshcore-runner-2]. That runner has not picked up a job since at least 2026-08-31. Without a timeout the queued job held the master concurrency group open and GitHub cancelled every later master push (details in #1922).

What is in place now, as a workaround and not a fix:

• the job has timeout-minutes: 10 and is gated behind the repository variable ENABLE_STAGING_DEPLOY (.github/workflows/deploy.yml:845-867);
• badges no longer depend on the deploy job;
• master pipelines complete again: the latest master run (a2f039d4, 2026-09-12) passed Go, race detector, Playwright E2E and the Docker build, with Deploy Staging skipped.

So nothing merged since 2026-08-31 has been deployed to the owner's staging instance. Only the owner can bring the runner back, point the job at another runner, or decide that staging deploys from this repo stop.

2. Nobody active can change repository settings

Current roles: Kpa-clawbot admin; KpaBap and efiten write. With write access no one can:

• set branch protection, rulesets or required reviews on master;
• set the ENABLE_STAGING_DEPLOY variable or other repository settings;
• grant access to further contributors.

Merging currently relies on the rules from #1922 (one merge at a time, green Go and E2E jobs, no merging of one's own PRs without a second reviewer). Those are self-imposed. Branch protection with a required review would make them enforced instead.

Asks

1. Restore or retire meshcore-runner-2, and say which.
2. Grant maintain to one or more active contributors, or name who should hold it.

Either answer is useful on its own. If you want the interim maintenance to stop, one line here is enough.

[efiten]

Record-keeping on the merge rule from #1922 ("no merging of my own PRs without a second reviewer").

Ten of my own PRs are ready: #2015, #2016, #2017, #2018, #2019, #2020, #2021, #2022, #2023, #2025. No second human reviewer is available for them, so I am merging them with an independent automated review as the second pass instead. Each PR was reviewed separately, from a cold context, by a review agent that did not write the code and was asked to find defects and back each one with a failing test, a reproduction or a firmware reference. The findings and what changed because of them are in a "Review follow-up" comment on each PR. That review closed #2011 outright, split #2025 out of #2023, and reworked #2021 and #2023 before they left draft. Every PR was also run on a staging instance with live traffic.

This is a deviation from the rule as written, stated here so it is visible. The rest of the rule stands: one merge at a time, green Go and E2E jobs on the head being merged. Anyone who wants a human review on one of these before it lands can say so on that PR, and I will not merge it while that request is open.

Once someone holds maintain (ask 2 above), required reviews on master would make this decision unnecessary.