feat(workflows): default every shared workflow to ARC; public repos use GitHub's runner

[JesperTerkelsen]

What?

Makes the self-hosted ARC runners the default for every shared workflow, not just the Kotlin ones, and moves public repos to GitHub's standard runner.

Workflow	Change
deploy-generic, deploy-generic-v2, deploy-python	New use-arc-runners input (default true), passed down to component-build / component-test-python
pull-request-bun, pull-request-react, component-test-python	New use-arc-runners input (default true). Setup runs on arc-arm64-2cpu-4gb on ARC; the main job's runner comes from the converter
component-build	Default flips from false to true, so its direct callers move too. The Blacksmith builder job is never selected in a public repo
runner-size-converter	Returns ubuntu-24.04-arm whenever github.event.repository.private is false, whatever the inputs. ARC is only returned for private repos

Every read is (inputs.use-arc-runners && github.event.repository.private), as in the Kotlin workflows (#360). The ARC runner group also disallows public repositories (https://github.com/monta-app/kube-manifests/pull/7727).

Who moves

From an org-wide scan of all 307 non-archived repos:

• ~45 private repos move from Blacksmith to ARC with no change in the repo: about 33 via deploy-generic(-v2), 11 calling component-build directly, plus service-grid's pull-request-react job.
• library-ocpp and ocpp-emulator (public) move from Blacksmith to ubuntu-24.04-arm. Their PR workflows used to fall back to Blacksmith because ARC is private-only.

Not affected:

• Repos pinned to an older github-workflows commit: grid, charges, energy, energy-meter, bridge, lakehouse-webhooks, knowledgebase (@f0866ab), and internal-ocpi-tooling's PR workflow (@b65d4f5).
• Jobs with runs-on: blacksmith-* written directly in the repo: service-agentic, data-slm-pipeline, service-ocpp, server, service-control, service-identity-ui. These get per-repo PRs.
• Scheduled runs (no repository in the event payload) keep their current behaviour.

Test plan

After merge, each affected repo's next deploy runs on ARC. Rather than an opt-in PR and a revert per repo, the follow-up per-repo PRs pass the GH_ACTION_* S3 secrets, which the ARC image build uses for its cache-mount storage. Merging each one triggers that repo's first ARC deploy. They go out one team at a time, and each team's results are checked before the next.

Risks

• Package installs inside docker build. Most of these images run npm/pnpm/pip inside the Dockerfile. The runner's CodeArtifact proxy (npm via the job-started hook) doesn't reach inside the build, so cold builds hit the public registries from the shared NAT IP, and npm/PyPI could rate-limit. The Dockerfile cache mounts (feat(build): keep Dockerfile cache mounts between ARC image builds #359) keep warm builds off the registries.
• First builds are cold. The ECR layer cache and the cache mounts start empty on ARC.
• Rollback is reverting this PR, or setting use-arc-runners: false in a repo.

🤖 Generated with Claude Code