CI never actually builds the generated Package.swift or Gradle module

[saimskywalker]

Problem

The generator's whole value proposition is a Package.swift and build.gradle.kts that behave correctly under real Swift Package Manager and AGP/Gradle resolution — including subtle, previously production-hit failure modes the code comments call out explicitly (SPM's three-location manifest-content cache, AGP 9.1 rejecting kotlinOptions/sourceSets.java.srcDir at script compilation, bundleDebugAar refusing a direct local .aar). None of that is exercised by CI: the single ubuntu-latest job only checks that a template expression didn't leak (grep) and that the generated shell scripts parse (bash -n). It never invokes swift package resolve / swift build against the generated Package.swift, and never runs Gradle against the generated build.gradle.kts — so a regression in either manifest (e.g. reintroducing kotlinOptions, or a Package.swift that fails to resolve) would pass CI green.

Evidence

• .github/workflows/ci.yml (entire file) declares only one job, runs-on: ubuntu-latest (line 13) — there is no macos-latest runner, and no job invokes gradle/./gradlew or a JDK setup action.
• The "Generated output is valid" step (.github/workflows/ci.yml:27-49) does exactly three checks on the generated files: a grep -rq '${spec\.' leak check (line 38), bash -n on the fetch scripts (line 45), and a test ! -f .../pubspec.yaml for the native flavour (line 49). It never calls swift build, swift package describe, or a Gradle task against either generated package.
• README.md:139-158 ("Four traps this generator already walks around") documents exactly the class of bug — AGP script-compilation rejections, SwiftPM's content-keyed manifest cache — that only a real Swift/Gradle invocation on Ubuntu-vs-macOS-appropriate toolchains would catch; on Linux, Gradle/AGP validation of the Android module is achievable today (no macOS runner needed), but nothing in CI does it.

Proposed fix

Extend .github/workflows/ci.yml with two checks against the already-generated /tmp/flutter and /tmp/native output:

1. A Gradle job (can stay on ubuntu-latest) that runs a real AGP/Gradle task (e.g. gradle :module:assembleDebug or at minimum gradle :module:help/tasks) against the generated android/build.gradle.kts for both the "no .aar present" and ".aar present" (a dummy zero-byte or minimal placeholder .aar) cases, to catch the kotlinOptions/sourceSets and bundleDebugAar regressions the README warns about.
2. A macos-latest job that runs swift package resolve (or swift build) against the generated Package.swift for both flavours, with and without a placeholder .xcframework dropped into Frameworks/, to catch a manifest that fails to resolve.

Acceptance criteria

• CI fails if a future template change reintroduces kotlinOptions { } inside android { } or sourceSets { java.srcDir(...) }.
• CI fails if a future template change produces a Package.swift that does not resolve, in either the binary-absent or binary-present branch.
• The new jobs run against output generated by the existing dart run bin/binary_sdk_bridge.dart invocations already in the workflow, for both --flavor flutter and --flavor native.