[codex] Build and release installable app artifacts

[SebastianBoehler]

What changed

• Reworked the Flutter GitHub Actions workflow into a multi-platform build/release pipeline.
• Builds Android APK, web bundle, Linux x64 bundle, macOS app zip, and Windows x64 zip artifacts.
• Skips iOS because distribution needs Apple signing and App Store/TestFlight handling.
• Publishes GitHub Release assets on v* tags, manual workflow runs with release_tag, or a flutter_app/pubspec.yaml version-line change on main.
• Adds SHA-256 checksum files next to each downloadable artifact.
• Updates README install instructions for all supported artifact platforms.

Validation

• Parsed .github/workflows/flutter-ci.yml with PyYAML.
• Ran git diff --check.
• Confirmed subosito/flutter-action@v2 is the documented action major version.

Notes

The workflow intentionally does not publish iOS builds. Android APKs are still signed with the Flutter Android runner debug signing configuration, so they are suitable for course testing but not app-store distribution.

[SebastianBoehler]

Smallest useful next action: tighten the README wording so it exactly matches the workflow triggers.

Intent looks good: this PR documents where students can find installable Android APKs and calls out the current sideloading/debug-signing caveat. The likely risk area is discoverability accuracy: the workflow currently runs on PRs only when .github/workflows/flutter-ci.yml or flutter_app/** changes, and on pushes only to main or v* tags. A README-only PR like this one does not produce an APK artifact, and arbitrary branch pushes do not either.

Useful review angle: check the install instructions against .github/workflows/flutter-ci.yml, especially trigger conditions, artifact name, release upload behavior, and whether “release APK” plus “debug signing configuration” is understandable for course testers.

Concrete next step: adjust the first artifact bullet from “For branch and pull request builds...” to wording like “For main, manually dispatched, or Flutter/workflow PR builds...” or split it into separate main/PR/manual cases. After that, git diff --check is enough validation for this docs-only PR.

[SebastianBoehler]

Follow-up from the Discord request: the multi-platform release workflow is prepared locally, but pushing the commit is blocked because this runtime token cannot create or update .github/workflows/flutter-ci.yml without GitHub workflow scope. The intended change builds Android, web, Linux, macOS, and Windows artifacts, skips iOS, and publishes releases on v* tags, manual release tags, or a flutter_app/pubspec.yaml version change on main. A maintainer with workflow permission needs to apply/push that workflow commit.

[SebastianBoehler]

Workflow commit pushed successfully now that workflow updates are permitted. PR #27 includes the multi-platform artifact workflow and README install instructions.