ROFL deploy/replace-machine can leave active replicas running while configured machine pointer stays accepted (EXPIRED) and machine logs return 404

首先使用 oasis rofl show --format json、machine show、machine logs --yes 和 deploy --replace-machine --yes 重现 managed-provider 流程，并参考相关 issue #487、#580 和 #584。跟踪替换操作如何报告 machine ID 和就绪状态。完成的标准是：显示一台全新且可运行的 machine，并且其 logs 可访问；或者在替换未能收敛时，CLI 明确安全地失败。

Summary

We are seeing a confusing ROFL operational state on testnet:

• oasis rofl show --format json reports active replicas
• the configured machine pointer still resolves to a machine that shows accepted (EXPIRED)
• oasis rofl machine logs --yes for that machine returns 404 Not Found
• oasis rofl deploy --replace-machine --yes does not give us a reliable operator-visible signal that a fresh machine was actually rented and started

This makes it hard to tell whether a new rollout really happened, and it blocks strict-mode validation of our ROFL app.

Environment

• Oasis testnet
• ROFL app using managed provider flow
• CLI version in active use on 2026-04-12

Observed behavior

1. oasis rofl show --format json shows active replicas.
2. oasis rofl machine show for the configured machine ID shows accepted but also expired state.
3. oasis rofl machine logs --yes returns 404 Not Found.
4. oasis rofl deploy --replace-machine --yes completes, but from the operator point of view we still cannot confidently observe a fresh machine start.

Expected behavior

One of the following should happen clearly:

• a fresh machine ID is created and surfaced to the operator, with logs available, or
• the CLI should fail closed and state that replace-machine did not converge to a fresh runnable machine

Why this matters

From the application side, we can see that active replicas exist, but we cannot correlate them to a fresh rollout with accessible logs. That makes rollout validation ambiguous and turns debugging into guesswork.

Related issues

• oasisprotocol/cli#487
• oasisprotocol/cli#580
• oasisprotocol/cli#584

Additional context

This is not the same as the previously diagnosed evm.SimulateCall / secure query limitation. We already worked around that at the application layer. The remaining blocker is specifically machine lifecycle / rollout observability.