flowey: take the size check baseline from in-progress CI runs (#5035)

The `verify openhcl binary size` jobs look for an `openvmm-ci.yaml` run
on the PR's merge base, or on one of its 10 parents, that has completed
and whose `build openhcl` job succeeded. That job publishes the
baseline, but the run completes only when its slowest jobs do. Since
16:37 UTC today, every `openvmm-ci.yaml` push run on `main` has stayed
queued behind `run vmm-tests [x64-windows-amd-snp]`, which needs the
single bare-metal SNP runner and which the check-in gates do not
require. Since about 21:00 UTC, every PR run's size check has failed
with `Failed to get action id after 10 attempts`: 19 runs across 13 PRs.
Each of those `main` runs had already published its
`x64-openhcl-baseline` and `aarch64-openhcl-baseline` artifacts.

#4930 widened the search from 5 to 10 commits for the same reason, and
its review noted that the root problem is that baseline updates do not
keep up with `main`. This change makes a baseline usable as soon as the
build that publishes it finishes.

## Summary

- accept an `openvmm-ci.yaml` run in any state once the `build openhcl`
job that publishes the baseline has succeeded, instead of waiting for
the whole run to complete

## Validation

On Windows x86-64:

- `cargo check --locked -p flowey_lib_hvlite`: passed
- `cargo clippy --locked --all-targets -p flowey_lib_hvlite`: passed,
with no warnings in `flowey_lib_hvlite`
- `RUSTDOCFLAGS="-D warnings" cargo doc --locked --no-deps -p
flowey_lib_hvlite`: passed
- `cargo nextest run --locked --profile agent -p flowey_lib_hvlite`: 24
passed
- `cargo xtask fmt --fix`: passed; `verify-flowey` regenerated the
pipelines without changes

Against live runs, using the `gh` commands that `gh_workflow_id` issues,
without `-s completed`:

- `6e8c813d4`, the merge base of #4591, whose size checks failed,
resolves on the first lookup to run 42899073943, which is still queued.
`ecb13803a`, the current `main`, resolves to run 42920336870, also still
queued. Both runs have successful `build openhcl [x64-linux]` and `build
openhcl [aarch64-linux]` jobs.
- `gh run download 42899073943 -R microsoft/openvmm --pattern
x64-openhcl-baseline` succeeds while the run is still queued.
- `cargo xtask verify-size` between those baselines and the binaries
that #4591's failed jobs uploaded reports a total difference of 0 KiB on
x64 and 5 KiB on aarch64.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: ppenna

flowey/flowey_lib_hvlite/src/_jobs/check_openvmm_hcl_size.rs

@@ -87,12 +87,16 @@ impl SimpleFlowNode for Node {
             base_branch,
         });
 
+        // The baseline is published by the build job, so accept a run that is
+        // still in progress once that job has succeeded. Waiting for the whole
+        // run would tie the baseline to its slowest jobs, such as VMM tests
+        // queued for scarce self-hosted runners.
         let merge_run = ctx.reqv(|v| gh_workflow_id::Request {
             repo_owner: crate::common::OPENVMM_GITHUB_OWNER.into(),
             repo_name: crate::common::OPENVMM_GITHUB_REPO.into(),
             commit_or_branch: gh_workflow_id::GitCommitOrBranch::Commit(merge_commit),
             pipeline_name,
-            require_run_status: Some(gh_workflow_id::GhRunStatus::Completed),
+            require_run_status: None,
             require_successful_job_with_name: Some(job_name),
             gh_workflow: v,
         });