[mishamyte]

The dev build on main has failed on macOS and iOS since d10fe8a (#492) —
two runs red, and the merge before that one was the last green release run.
Nothing on a pull request could have caught it.

[!] CocoaPods could not find compatible versions for pod "Firebase/CoreOnly":
      In snapshot (Podfile.lock):
        Firebase/CoreOnly (= 12.15.0, ~> 12.15.0)
      In Podfile:
        firebase_core (from `…/plugins/firebase_core/macos`) was resolved to
        4.15.2, which depends on
          Firebase/CoreOnly (~> 12.19.3)

#492 moved firebase_core 4.11.0 → 4.15.2. Its podspec asks for a newer
Firebase pod than the committed lock names, and pod install keeps a locked
version for a transitive pod even when the development pod above it changed.
CocoaPods says so itself, in the second of the two causes it prints:

changed the constraints of dependency Firebase/CoreOnly inside your
development pod firebase_core. You should run pod update Firebase/CoreOnly to apply changes you've made.

The error message blames the wrong thing, and I believed it first

Flutter appends this:

Error: CocoaPods's specs repository is too out-of-date to satisfy dependencies.
To update the CocoaPods specs, run:
  pod repo update

That is not a diagnosis. cocoapods.dart's _diagnosePodInstallFailure does
stdout.contains('out-of-date source repos'), and CocoaPods prints that phrase
for both causes it lists — so Flutter reprints the stale-index remedy
whichever one applies, then throws. It never retries with --repo-update
(pod install --verbose is the only invocation in the file; the string
repo-update does not appear in it at all).

The first version of this branch took that advice and added a pod repo update
step. The verbose log of run 43110342556 shows it would have been a no-op:

Adding spec repo `trunk` with CDN `https://cdn.cocoapods.org/`
…
CDN: trunk Relative path downloaded:
  Specs/0/3/5/Firebase/12.19.3/Firebase.podspec.json, save ETag: …
CDN: trunk Relative path: Specs/0/3/5/Firebase/12.19.3/Firebase.podspec.json
  modified during this run! Returning local

There is no baked index on the image to be stale — the trunk repo is created
during the run, and 693 podspecs are fetched fresh over the CDN with new
ETags. The exact version the resolver needed, 12.19.3, was downloaded and read
seconds before the failure. The 12.15.0 in the error is labelled In snapshot (Podfile.lock): it is our own committed file, which I had read as a ceiling in
the index.

pod install --repo-update would fail identically — refreshing sources does
not unlock a pinned pod.

So the snapshot is the problem, and the snapshot cannot be maintained here

Committing Podfile.lock is the usual advice, and it assumes somebody can
regenerate it. In this project nobody can:

• both build scripts refuse a non-Darwin host outright (uname -s → exit 1),
• ci.yml is analyze plus the BSD script tests and builds no Apple target,
• the release job is the only thing in the whole project that ever runs
  pod install.

So a plugin bump invalidates two tracked files that no reviewer, no gate and no
local run can notice, and the first sign is a red release. That is t16
exactly: #492's own CI was green because nothing on a pull request compiles.

What is lost is narrow. pubspec.lock still pins every plugin to an exact
version, and each plugin's podspec pins the pods it needs — so what floats is a
third-party pod's patch range inside a ~> it already declared. What is gained
is a release that does not break on every plugin bump.

And it is reversible from real files rather than from a guess. The release
job now uploads the pair it resolved as podfile-locks. Commit that pair and
drop the two .gitignore lines, and the project is back to pinning — with a
lock that is actually correct, which is not true of the one in main today.

Why those steps are last in the job

      - name: Upload the resolved Podfile.lock files
        if: ${{ !cancelled() }}
        continue-on-error: true

Upload macOS and iOS release assets above it carries no if:, so it defaults
to success(). A diagnostic step failing ahead of it would skip the DMG and IPA
upload, skip publish, and lose a release that was already built — the hazard
the Sentry step guards against the same way. !cancelled() rather than
success() because a run where macOS resolved and iOS then failed is exactly
when the resolved lock is worth having, and if-no-files-found: warn rather
than error because a step whose only output is a diagnostic must not redden a
release.

Verified

• ASSET_RETENTION is defined at workflow level, so it is in scope here; the
  asset upload in the same job already uses the identical expression.
• Nothing else in the repository reads either lock file (grep over *.sh,
  *.dart, *.yml, *.md, excluding lib/modules/).
• The workflow parses and the three closing steps are in the intended order,
  with the new one last.
• Flutter's behaviour was read in
  flutter_tools/lib/src/macos/cocoapods.dart (_runPodInstall line 352,
  _diagnosePodInstallFailure line 392, the reprinted advice line 410), not
  inferred from the console output.
• The log claims above are quoted from run 43110342556's own verbose output,
  not summarised.

What this does not prove: that the next release run goes green. Nothing
here can build iOS or macOS, so the first evidence will be the dev build after
this merges. If pod install then finds another pin it cannot satisfy, it will
say so with the same clarity.

Not in this PR

• No CHANGELOG entry. Deliberate: nothing a user can observe changes.
• A gate that would have caught Update dependencies in waves, and hold the two that are not safe yet #492. The real hole is at pull-request
  time, and closing it needs no Mac: after flutter pub get on the Linux
  analyze job every plugin's podspec is in ~/.pub-cache, so a script can
  read each s.dependency requirement and assert the lock satisfies it — the
  same check pod install performs, and it would have failed on Update dependencies in waves, and hold the two that are not safe yet #492's own
  diff. Moot while the locks are out of git, and the thing to build first if
  they come back.
• t12, the guard on the Gradle pins, still open from Take AGP 8.13 with the Kotlin it requires, and make the pins stick #494.