Clarify test expectations for latest-alpha-cli releases

What is the expected test policy for alpha releases published from latest-alpha-cli, and what should contributors do if post-merge CI finds a regression?

The workflow documentation says that Cargo-native PR checks are intentionally small and that the full Cargo nextest matrix runs post-merge. The release workflow updates latest-alpha-cli after the release job, but I do not see the full test workflow among that job's dependencies. Is there an additional release gate or policy that is not documented here?

A full-suite-passing alpha would provide downstream contributors with a known-good baseline: when a test fails after their change, they could more quickly identify their change as the cause. Without that baseline, they first need to run the full suite against an unmodified alpha to determine whether the failure already exists upstream.

For a concrete example, PR #39372 left an existing TUI test failing because its test recorder changed; the regression is described in #40238. The production change appears valid, but the alpha branch can contain a failing test unless the full suite is run and acted on before publication.

Read .github/workflows/README.md and .github/workflows/rust-release.yml, then compare the documented Cargo nextest workflow with the release job dependencies. Confirm the expected alpha-release gate and post-merge regression response with maintainers; done means the policy and any required workflow relationship are documented clearly.