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

Inizia riproducendo il flusso di managed-provider con oasis rofl show --format json, machine show, machine logs --yes e deploy --replace-machine --yes, usando come contesto le issue correlate #487, #580 e #584. Traccia il modo in cui la sostituzione segnala l'ID della macchina e la sua disponibilità. Il lavoro è completato quando viene resa disponibile una macchina nuova ed eseguibile con log accessibili, oppure quando la CLI fallisce chiaramente in modo sicuro se la sostituzione non converge.

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.