[eas-cli] recognize queued workflow runs and report finishedAt only for final runs

[hSATAC]

Why

Queue semantics for workflow concurrency added a WAITING run status: a run queued behind its concurrency group until the run holding the group finishes. eas-cli currently treats it as just another transient status — polling keeps working, but nothing explains why a run isn't starting, queued runs can't be selected in workflow:cancel, and run listings print a bogus finish time for runs that haven't finished.

How

• workflow:run --wait and workflow:status show a queued run as Workflow run is queued: Waiting for <run name>, naming the run that holds the group via the new blockingWorkflowRun field. When that run is itself waiting on user action (an approval gate or a device registration), the spinner appends — it needs your action first: <link to the run>, matching the CLI's link-out convention for actions that happen on the website. The wording leads with "queued" to match the website's label for this state.
• workflow:runs reports finishedAt only for final statuses, reading the server's finalizedAt instead of updatedAt (which any later write to the row refreshes). Final runs predating the finalizedAt column report null rather than an approximated time.
• workflow:cancel includes queued runs in the interactive picker. While in there, this also fixes --non-interactive, which was parsed but never applied (the command scanned argv for the flag, but oclif consumes declared flags out of argv), so automation could hang on the interactive picker.
• The committed GraphQL snapshot is regenerated from production plus a hand-added blockingWorkflowRun field, which ships with the www concurrency stack. Once that stack is live, yarn generate-graphql-code should reproduce the snapshot with no diff.

Merge gate: do not merge until expo/universe#30099 is live in production — the polled query selects blockingWorkflowRun at runtime, so a release cut before that deploy would break workflow:run --wait and workflow:status. Gating the merge instead of the release keeps main releasable at all times.

Test Plan

Jest covers finishedAt for every status (including the finalizedAt preference and the legacy fallback), the cancel picker listing both in-progress and queued runs, and two --non-interactive regressions. Lint, format, typecheck, and the changelog check are green.

[linear-code]

ENG-25945

[codecov]

Codecov Report

❌ Patch coverage is 57.14286% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 63.80%. Comparing base (790231e) to head (573db07).

Files with missing lines	Patch %	Lines
...ackages/eas-cli/src/commandUtils/workflow/utils.ts	16.67%	15 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4258      +/-   ##
==========================================
+ Coverage   63.76%   63.80%   +0.05%     
==========================================
  Files        1030     1030              
  Lines       47497    47516      +19     
  Branches     9993     9998       +5     
==========================================
+ Hits        30280    30313      +33     
+ Misses      17116    17102      -14     
  Partials      101      101              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

✅ Thank you for adding the changelog entry!

[github-actions]

Subscribed to pull request

File Patterns	Mentions
packages/eas-cli/**	@douglowder
packages/eas-cli/src/commands/workflow/**	@sjchmiela

Generated by CodeMention

Warning: The preamble and epilogue options in commentConfiguration are deprecated. Use template instead.

[hSATAC]

Heads up: the failing GraphQL schema check is expected for now. This PR uses blockingWorkflowRun from expo/universe#30099, which isn't in production yet, so the live-schema validation fails.

Review can proceed in the meantime — the check should go green once #30099 is deployed.