ci: stop GitHub-hosted runners on automatic workflows

[loverustfs]

Intent

Automatic runs no longer use GitHub-hosted (billed) runners. Linux jobs move to the organization self-hosted label sm-standard-2. macOS and Windows tests and installers cannot be cross-compiled on Linux into the same results, so they are removed from push, pull_request, schedule, tag, and Release events and kept only on workflow_dispatch. Test commands and packaging steps are unchanged.

The runner group may still need to grant this repository access. If Linux jobs stay queued after merge, allow rustfs/launcher to use sm-standard-2 in the organization's self-hosted runner group.

Runner for each job

Workflow	Job	Old runner	New runner	Trigger
ci.yml	check (Check and Test)	ubuntu-latest	sm-standard-2 (60 minute timeout)	push to main and pull_request, unchanged
ci-native.yml	test-native (Windows)	windows-latest on push/PR	still windows-latest (45 minute timeout)	workflow_dispatch only
ci-native.yml	test-native (macOS)	macos-latest on push/PR	still macos-latest (45 minute timeout)	workflow_dispatch only
upstream-sync.yml	check-upstream	ubuntu-latest, hourly	sm-standard-2 (15 minute timeout)	daily at 02:00 UTC, plus manual dispatch
upstream-sync.yml	trigger-build	ubuntu-latest, and it ran gh workflow run build.yml	sm-standard-2 (10 minute timeout); it only prints manual-build instructions	when a new version is found
build.yml	build-check	ubuntu-latest	sm-standard-2 (15 minute timeout)	workflow_dispatch only
build.yml	build macOS Apple Silicon	macos-latest on tag/Release	still macos-latest (120 minute timeout)	workflow_dispatch only
build.yml	build macOS Intel	macos-15-intel on tag/Release	still macos-15-intel (120 minute timeout)	workflow_dispatch only
build.yml	build Windows	windows-latest on tag/Release	still windows-latest (120 minute timeout)	workflow_dispatch only
build.yml	upload-release-assets	ubuntu-latest	sm-standard-2 (30 minute timeout)	only as part of the manual workflow

The four rows marked "still" bill GitHub-hosted runners when someone starts that workflow by hand. Push, pull request, schedule, and tag events no longer select those labels.

Why these jobs are not cross-compiled on Linux

• Native tests compile and execute on the target OS: cargo clippy, cargo test --no-run, a rustc --test binary for network.rs, and on macOS the full cargo test suite. The Windows harness fails to start (STATUS_ENTRYPOINT_NOT_FOUND); that check needs a real Windows runner. Cross-compiling on Linux would not run the same tests.
• macOS installers call codesign and build a DMG with Tauri (hdiutil). Those tools exist only on macOS.
• Windows installers use cargo tauri build --bundles nsis, and the artifact step follows runner.os == 'Windows' into PowerShell. The NSIS/MSVC toolchain on the current sm-standard-2 image cannot reliably produce the same installer.
• The organization has no self-hosted macOS or Windows runners. Linux labels in use elsewhere are sm-standard-2, sm-standard-4, and dind-sm-standard-2. Checks and compiles here use sm-standard-2.

upstream-sync still creates a git tag when it finds a new version. It no longer calls gh workflow run build.yml, because the daily schedule would otherwise start billed macOS and Windows builds. To publish installers, run Build and Release manually:

gh workflow run build.yml --ref v0.1.0 -f tag=v0.1.0 -f publish=true

publish defaults to false.

Verification

• actionlint v1.7.12 reports no problems in .github/workflows.
• Rust CI was not run in this environment. check will run on GitHub after sm-standard-2 can pick up this repository.