confusing zone status after inconsistent persistent state has been wiped

[Philip-NLnetLabs]

When cascaded has trouble restoring persistent zone state, it starts empty for a the affected zone. However the zone status command indicates otherwise:

$ cargo run --bin cascade zone status nl 
 [...]

last published
  loaded serial: 2026071042
  signed serial: 2026071001
  timestamp:     2026-07-10T21:21:53.645178747Z
  size:          51511558 records

[...]

[ximon18]

I think whether or not the information shown is correct or not is a matter of perspective.

Cascade did load the zone with the specified serial and it did publish a signed version of the zone with the specified serial, it just no longer has the data to be able to publish it now.

So either:

• Update the zone status output to be clearly indicate that last published also means currently published, and set last_published = None when restoration is abandoned, or
• Show a warning on zone status output that restoration failed and the last published zone is no longer being served.

I think the latter is preferable as the former hides that a problem occurred.

[bal-e]

I think #877 fixes this; it separately tracks the "previously persisted instance" from the "currently published instance". When zone restoration succeeds, it copies data from the previously persisted instance to the currently published instance; if it fails, the currently published instance is left empty. We can follow up by enhancing zone status to show details of the previously persisted instance if there is no currently published instance.