Help wanted: expand deterministic end-to-end coverage

## Goal BuildMax already has deterministic E2E coverage for the CLI/TUI, Desktop bridge, and key Portal/deployment flows. We would like community help extending coverage to important user journeys that unit, handler, and integration tests cannot prove across real boundaries. The goal is not to recreate the unit-test suite through a browser or deployment. Each contribution should prove one meaningful end-to-end outcome. ## Ground rules - Tests must be deterministic: use the committed mock model, not a provider API key, personal account, or external SaaS. - Keep fixtures isolated. Never use a contributor real `BUILDMAX_HOME`, credentials, workspace, or persistent resources. - Add the test at the lowest level that proves the cross-boundary claim. - Retain useful diagnostics on failure: scenario/transcript, logs, and browser trace or screenshots where applicable. - Keep each PR focused on one journey or enabling capability. See the current E2E design and contributor runbook: - https://github.com/gougoujiang/buildmax/blob/main/docs/design/end-to-end-testing.md - https://github.com/gougoujiang/buildmax/blob/main/docs/contribute/testing.md ## Good contribution areas - [ ] Portal browser coverage for workflow execution and space settings. - [ ] Deployment-level cancellation: prove a cancellation signal reaches a live worker execution and leaves the run in the correct terminal state. - [ ] Deployment-level failure recovery: prove that a worker dying mid-run leaves a terminal, diagnosable run with retrievable logs or artifacts. - [ ] A small packaged Desktop-app smoke test on supported native runners. The cancellation and failure-recovery work need an enabling change first: the deployment mock must serve multiple explicit scenarios selected by model alias. Please discuss the proposed boundary before starting that item. ## How to contribute 1. Comment on this issue with the path you would like to take. 2. We will link or create a focused implementation issue with exact acceptance criteria and verification commands. 3. Start with the narrowest relevant command, for example: ```text ./make e2e cli ./make e2e desktop ./make e2e local ./make e2e compose ./make e2e kind ``` 4. Include the command and relevant retained artifacts in the PR description. Thanks for helping make BuildMax user-facing flows easier to trust and safer to change.