test: add verification and rolling upgrade test for Rust launcher

[barakeinav1]

Summary

• Add test-verify-and-upgrade.sh script for Rust launcher localnet testing
• Scenario 1 (verify): Validates cluster is fully operational — checks contract state, TEE accounts, real Dstack attestation (not Mock), ECDSA signature generation, and allowed image hashes
• Scenario 2 (upgrade): Tests rolling upgrade — votes for new MPC image hash, waits for node detection, restarts CVMs with updated TOML config, verifies network with new image

Depends on #2326 and #2563.

Closes #2599

Test plan

• Scenario 1 verified against running 2-node Rust launcher cluster — all checks pass
• Scenario 2 (upgrade) end-to-end test with a different MPC image tag

🤖 Generated with Claude Code

[claude]

PR title type suggestion: This PR modifies source code files across multiple crates in addition to adding tests, so the type prefix should be feat: instead of test:. The test type is appropriate only when test files are changed exclusively.

Suggested title: feat: add verification and rolling upgrade test for Rust launcher

[claude]

Code Review

The PR introduces a new Rust-based TEE launcher (crates/tee-launcher/) and associated localnet deployment/testing scripts. The Rust code is well-structured with good test coverage (unit tests with httpmock, integration tests gated behind a feature flag).

No critical issues found. A few minor observations:

• Blocking I/O in async context (main.rs:438-462): std::process::Command calls for docker pull and docker inspect block the tokio runtime thread. Since main is the only task, this is fine in practice, but if the launcher ever gains concurrent work, these should become tokio::process::Command. Not blocking given current usage.

• expect on docker inspect output (main.rs:475): .expect("is valid digest") will panic if Docker returns unexpected output (e.g., error text instead of a digest). This is after a success check on inspect.status, so it should be safe in normal operation, but a proper error return would be more defensive. Minor.

• The compose template uses simple string replacement ({{IMAGE_NAME}}, {{PORTS}}, etc.) which works here because all values are validated types (DockerSha256Digest, NonZeroU16, etc.) that cannot contain template injection characters. Good.

• The DockerTokenResponse.token field is logged indirectly via tracing::info on the compose file but the token itself is not directly logged. The bearer token is constructed in-memory only. No credential leak concern.

✅ Approved — clean new crate with solid type safety, good test coverage, and no merge-blocking issues.

[claude]

PR title type suggestion: This PR changes source code files across multiple crates, not only tests. The test: type should only be used when ONLY test files are changed. It should probably be feat: instead.

Suggested title: feat: add verification and rolling upgrade test for Rust launcher

[claude]

PR title type suggestion: This PR includes significant source code changes across multiple crates beyond just tests. The test: prefix is appropriate only when changing test files exclusively.

Based on the scope of changes (source code updates, CI changes, configuration), consider using feat: instead if these are new capabilities, or another type that better reflects the primary intent.

Suggested title: feat: add verification and rolling upgrade test for Rust launcher

[claude]

PR title type suggestion: This PR includes substantial source code changes across multiple crates, not just test files. The type prefix should probably be feat: instead of test:.

Suggested title: feat: add verification and rolling upgrade test for Rust launcher