Fix wake recovery after snapshot restore timeout

[fcasal]

dropkit wake previously stopped waiting after five minutes, even when DigitalOcean was still restoring the droplet.
In the observed case, restoration took 6 minutes 35 seconds. Dropkit exited before configuring SSH, and retrying wake
refused because the droplet already existed, suggesting that it be destroyed or renamed.

This change allows retries to resume setup when the existing droplet’s source image matches the retained hibernation
snapshot. It also increases the default wait to 15 minutes, adds a configurable --timeout, and provides recovery
instructions when waiting times out. The snapshot is preserved if SSH configuration fails so setup can be retried.

[ret2libc]

Resuming an existing droplet can break its working SSH configuration. For example:

1. wake finishes Tailscale setup, updates SSH config to the Tailscale IP, and blocks public SSH through firewall lockdown.
2. The user interrupts at the snapshot-deletion prompt, leaving the snapshot available.
3. On retry, this PR accepts the existing droplet, but the code below overwrites its SSH entry with the public IP.
4. Tailscale setup then cannot connect through that SSH alias because public SSH is already blocked.

Previously, wake rejected existing droplets, so this path wasn’t reachable.

Could we preserve the working Tailscale address when resuming and add a regression test for retrying after firewall lockdown?