fix(vss): bound retry budget so builds fail fast when VSS is unreachable

[kaloudis]

Each HTTP request is already capped at 10s by vss-client's client-level timeout, but retry_policy() allowed 100 attempts with up to 180s of cumulative backoff — a single VSS operation could keep build_with_dual_store* blocked for several minutes. On mobile, that outlives the caller's watchdog timeout (180s on restore), which then abandons the build in a still-live thread over the shared storage dir — the root enabler of the timeout/cleanup race flagged in ZeusLN/zeus#4292 review.

Changes:

• Retry budget: 6 attempts / 30s total delay, base backoff 100ms (worst case ≈ 1 minute per operation, comfortably inside the mobile watchdog)
• Stop retrying AuthError — auth rejections (e.g. clock skew) cannot succeed on retry without new credentials

cargo check clean. Follow-up release + binary bump handled on the ZEUS side.

🤖 Generated with Claude Code

Trade-offs

• Backup-staleness window: a failed background VSS push is only logged and reconciled by the next session's bulk sync. Per-push outage tolerance drops from ~3+ minutes to ~1 minute. Acceptable under the local-first dual-store design; noting it for visibility.
• AuthError skip assumes fixed-header auth (deterministic server rejection, e.g. clock skew). Header-provider failures also map to AuthError, so an lnurl-auth deployment — where token fetches can fail transiently and succeed on retry — should not adopt this skip. Documented in the code comment.
• Standalone build_with_vss_store (not used by ZEUS): exhausted persist retries there can be fatal to LDK, so that deployment would want a larger budget. Also documented in the code comment.
• A slow-but-alive server (full 10s per request, eventually succeeding) can still stretch a multi-operation restore past the mobile watchdog — the ZEUS-side watchdog remains the backstop for that case.