feat(cli): show instance backups and their download URLs

[stackanthony]

Vast takes backups of customer instances and volumes into a company-managed bucket (e.g. before a machine is decommissioned). Customers currently have no way to see those backups exist, let alone retrieve them. This adds the read side.

Commands

vastai show instance-backups [--contract-id N]   # list, newest first
vastai show instance-backup-files CONTRACT_ID    # objects + short-lived download token

Backing API (already on the webserver): GET /api/v0/instance_backups/ and GET /api/v0/instance_backups/{contract_id}/download/.

Changes

File	+lines
vastai/api/storage.py	41
vastai/cli/commands/storage.py	87
vastai/cli/display.py	16
vastai/sdk.py	8

Additive only — 152 insertions, no deletions.

Notes for review

• vastai/ only. The deprecated vast.py is untouched, matching how recent features landed there (it gets sync'd for removals, not additions).
• The list epilog documents the restore path (vastai copy vast.CONTRACT_ID:/path INSTANCE_ID:/path) and the non-guessable asymmetry: an instance's filesystem lives under upper/, while a backed-up volume sits at the root of its own contract id.
• instance-backup-files prints the authorization token separately from the URLs, because the URLs 401 without it, and surfaces the server's truncated flag — a partial listing must not read as the whole backup when someone is verifying before wiping a machine.
• Backups outlive their instances, so entries stay listed after teardown; type reports unknown for a contract archived out of the live tables.

Testing

Verified end-to-end against a local stack with a real Backblaze account:

• both commands register and render help
• the api layer builds exactly /instance_backups/, /instance_backups/?contract_id=N, /instance_backups/N/download/
• a real 10 GB backup listed correctly (251 objects), and a 537 MB object downloaded with the token — byte count matched the manifest, and the same URL 401s without it
• CLI suite at baseline: 12 failed / 1518 passed / 12 errors both with and without this change (pre-existing test_tar_utils failures plus two network-dependent suites)