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

Empieza reproduciendo el flujo de managed-provider con oasis rofl show --format json, machine show, machine logs --yes y deploy --replace-machine --yes, usando los issues relacionados #487, #580 y #584 como contexto. Rastrea cómo el reemplazo informa del ID de la máquina y de su disponibilidad. Se considera terminado cuando se muestra una máquina nueva y ejecutable con logs accesibles, o cuando la CLI falla claramente de forma segura si el reemplazo no 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.