Flutter release 3.32.3 contained macOS Dart SDK binaries that were not codesigned (see #170536)

3.32.3 included an engine.version file that specified commit 31c4875. The code signing steps did not run in the build that produced the Dart SDK archives for that commit.
(see https://ci.chromium.org/ui/p/dart-internal/builders/flutter/Mac%20Production%20Engine%20Drone/21789/overview)

The build recipe uses RepoUtilApi.is_release_candidate_branch to determine whether a commit is part of a release branch (see https://flutter.googlesource.com/recipes/+/refs/heads/main/recipe_modules/repo_util/api.py#600).
If the commit is a release candidate, then the recipe will perform code signing.

31c4875 was part of the flutter-3.32-candidate.0 branch and should have been considered a release candidate. But that did not happen due to a race in RepoUtilApi.is_release_candidate_branch.

RepoUtilApi.is_release_candidate_branch checks if the build job's git_ref parameter references a branch named flutter-*-*-candidate. If so, it then queries Git to check if the commit being built matches the head of the git_ref branch.

But in this case, another commit (b02643b) landed on flutter-3.32-candidate.0 a few minutes after 31c4875. By the time LUCI ran the RepoUtilApi.is_release_candidate_branch logic, 31c4875 was no longer the head of that branch. So the recipe decided that 31c4875 was not a release candidate and did not run code signing.

Thanks to @matanlurey @jmagman @vashworth for investigating this.