ci: dev / main release pipeline

[patrickrb]

Summary

First PR in the new flow: lands the CI pieces that enforce the new flow. After this merges to dev and then to main, the repo owner enables branch protection rules (described at the bottom) and we're locked in.

The new shape

feature branch → PR → dev → (your PR) → main
                       ↓                  ↓
                  Play internal      Play internal
                  (dev-<N> tag)      (v* tag)
                                          ↓
                                    Play production
                                    (manual promote)

• dev is the integration target. Feature PRs land here. Each push auto-uploads to Play internal as dev-<run_number> and cuts a GitHub prerelease.
• main is the release branch. Each push auto-uploads to Play internal as the auto-bumped v* tag and cuts a normal GitHub release.
• dev → main PRs are the only PRs allowed into main, enforced by the new main-gate workflow as a required status check.
• Production promotion is a manual button-press in Play Console — never automatic. Pick the v*-named release, not a dev-* one.

Why two release streams

This lets us share an internal-track build of dev with testers continuously while keeping the main-branch lineage as the canonical "this is the next production candidate." Play Console will show both — distinguished by the releaseName field — so when it's time to promote, you can tell at a glance which build to pick.

What's in this PR

• .github/workflows/build-release.yml:
  • Drops the legacy capital-D Dev from push triggers; adds lowercase dev.
  • PR triggers now fire for PRs to main or dev (was main only) — feature → dev PRs get unit tests.
  • New dev branch lane in the tag-determination logic. Produces dev-<run_number> tags, marks the GitHub release as prerelease, uploads to Play internal alongside the v* releases.
  • softprops/action-gh-release honors the new is_prerelease output.
• .github/workflows/main-gate.yml (new):
  • Required PR status check on PRs to main.
  • Fails fast with a clear error message if the PR head branch isn't dev.

Branch protection setup (manual, after merge)

Once these workflows are on main, configure in GitHub Settings → Branches:

Rule for main:

• Require pull request before merging
• Require status checks: Unit tests (PR only), Build APK, enforce-source-is-dev
• Restrict who can push to matching branches: repo owner only
• Do not allow bypassing

Rule for dev:

• Require pull request before merging
• Require status checks: Unit tests (PR only), Build APK
• (no push restriction; feature branches need to flow in)

Test plan

• YAML lints clean (no Actions parser errors).
• Merge this PR to dev (no protection yet) — verify CI runs and produces a dev-N prerelease + Play internal upload.
• Repo owner PRs dev → main, merges, verifies the v* release path still works as it did before.
• Repo owner enables branch protection per the rules above.
• Future feature PRs target dev. Future dev → main PRs target main and are gated by enforce-source-is-dev.

🤖 Generated with Claude Code