Push: stuck wp.com sync lock with no inspect/cancel

## Summary

When two `studio push` invocations target the same WordPress.com site near-simultaneously, one wins the wp.com sync lock and the other (and **every** subsequent push) fails with:

```
✖ A sync operation is already in progress on this site. Please wait for it to finish and try again.
```

After 30+ minutes the lock remained held even though no `node main.mjs push` process was alive locally and no observable progress was happening on the remote. The CLI offers no way to inspect the lock holder, no way to force-cancel a stuck import, and no clear "wait until lock clears" affordance.

## Steps to reproduce

1. Have a wp.com Business site recently transferred to Atomic (`*.wpcomstaging.com`).
2. Run `studio push --remote-site --options plugins` twice in rapid succession (e.g. an interrupted attempt restarted before the first finishes the `initiateImport` step).
3. First push proceeds. Second returns the 409 above.
4. Every push after that, even hours later, returns the same 409.

## Expected

- Sync lock on the wp.com side has a bounded TTL (or a heartbeat that releases on failure).
- CLI exposes a way to inspect / cancel the active sync from the source host.
- Helpful error pointing at the next action ("a previous push is processing — eta ~5 min" / "stuck — run `studio push --reset-sync`").

## Actual

- Lock appears effectively permanent for >30 min after the last successful client call.
- Single line 409 with no remote ID, no last-modified timestamp, no recovery hint.
- Only workaround: manual plugin upload via wp-admin (entirely bypassing Sync).

## Environment

- Studio CLI: `1.9.0` (same behavior observed on `1.8.0`).
- macOS Sequoia, Apple Silicon.
- WordPress.com site on Business plan, transferred to Atomic (`*.wpcomstaging.com`) within the previous hour.

## Related: `preview update` does not push code or DB changes

Spotted during the same session and worth flagging because it sits in the same sync surface. `studio preview update ` completes ("Preview site available") but the remote keeps the previous state — changes made locally aren't reflected. `preview delete` + `preview create` was the only reliable way to push code into a preview, which rotates the `*-studio.wp.build` subdomain each time and forces external webhook re-registration on every iteration.

## Workaround for now

Until the lock clears or there's a reset path, the only way to land plugin code on a Business site with a stuck sync is to zip the plugins and upload via `wp-admin → Plugins → Add New → Upload Plugin`. Not great for the "Sync end-to-end" story.

Start by tracing the `studio push` flow through the `initiateImport` step and compare it with `studio preview update`, `preview delete`, and `preview create`. Done should include a recoverable stuck-sync path with lock inspection or cancellation and an actionable error, while preserving reliable preview updates.

Written by the indexing model from the issue text.