E2E coverage: assert download progress spinner renders under a PTY

Background

Copilot's review on #347 asked for observable-CLI-behavior coverage of the new download progress spinner (apps/rocm/src/cli_progress.rs), specifically for:

• rocm install sdk --format tarball (apps/rocm/src/therock.rs::install_tarball_runtime)
• ComfyUI source download (apps/rocm/src/comfyui.rs::download_and_extract_source)

The spinner only activates when stderr is a real TTY (std::io::stderr().is_terminal()), so the existing black-box suite — which spawns rocm with piped stdio via std::process::Command — can never observe it. Today neither download path has any E2E coverage, spinner or otherwise.

Why this isn't a quick fix

Both download paths resolve their source URL by talking to a real remote endpoint at runtime:

• install_tarball_runtime → therock_index_urls / resolve_tarball_artifact scrapes an HTML index page at channel.tarball_base_url() to find the newest matching tarball.
• ComfyUI uses a fixed COMFYUI_SOURCE_ARCHIVE_URL constant with no override hook.

Neither has an existing override hook, so a deterministic, network-independent test needs new test-only plumbing, not just a new feature file.

Proposed plan

1. Add a URL-override test hook, gated behind the existing e2e-test-hooks feature (see apps/rocm/Cargo.toml's e2e-test-hooks = [...] precedent), so:
   • resolve_tarball_artifact (and therock_index_urls) can be pointed at a local index URL instead of channel.tarball_base_url().
   • COMFYUI_SOURCE_ARCHIVE_URL can be overridden similarly.
2. Add a local fixture HTTP server (reusing tests/e2e-cucumber/src/mock_server.rs / http_server.rs / loopback_http.rs patterns already in the suite) that serves:
   • A minimal HTML index page in the same format parse_tarball_index_html expects, listing one fake tarball entry.
   • The tarball/archive body itself — small, deterministic bytes, ideally served with a throttle/delay so the download spans multiple progress repaints instead of completing in one chunk.
3. Drive each install path under a PTY using the existing harness (tests/e2e-cucumber/tests/e2e/tui_driver.rs, currently built for the interactive dash TUI but reusable for a plain scrolling stderr stream) or a lighter-weight PTY capture if the full vt100 screen-grid driver is overkill for a single-line carriage-return spinner.
4. New Gherkin scenarios, modeled on the existing PTY scenarios in install_lifecycle.feature, asserting:
   • The spinner line shows byte/percentage progress while the download is in flight.
   • The line is cleared (no stale fragment) before the next line of output.
   • Gate the scenario to the appropriate lane if it needs to be excluded from environments without PTY support (e.g. the therock case may need gating to the appropriate artifact/GPU lane).

Scope note

This was flagged during review of #347 (download progress indication) but deferred as a separate follow-up rather than rushed into that PR, since it requires new test infrastructure and a production test-hook design decision rather than a straightforward fix.

Duplicate

Duplicate/overlap with #373, filed independently off the same two Copilot review comments on #347 (https://github.com/ROCm/rocm-cli/pull/347#discussion_r3965111514, https://github.com/ROCm/rocm-cli/pull/347#discussion_r3965111538). Closing #373 in favor of this issue.

Start with apps/rocm/src/cli_progress.rs, apps/rocm/src/therock.rs::install_tarball_runtime, apps/rocm/src/comfyui.rs::download_and_extract_source, and the e2e-test-hooks feature in apps/rocm/Cargo.toml. Read tests/e2e-cucumber/src/mock_server.rs, http_server.rs, loopback_http.rs, and tests/e2e-cucumber/tests/e2e/tui_driver.rs before adding deterministic URL overrides and PTY scenarios modeled on install_lifecycle.feature. Done means both download paths show progress under a PTY and clear the spinner line without network access.