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

Bắt đầu bằng cách tái hiện luồng managed-provider với oasis rofl show --format json, machine show, machine logs --yes và deploy --replace-machine --yes, sử dụng các issue liên quan #487, #580 và #584 làm ngữ cảnh. Theo dõi cách thao tác thay thế báo cáo machine ID và trạng thái sẵn sàng. Được xem là hoàn tất khi một machine mới có thể chạy được hiển thị cùng với logs có thể truy cập, hoặc CLI chủ động thất bại một cách rõ ràng khi thao tác thay thế không hội tụ.

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.