Plan hangs on first deploy through a jump host

Reproduction

On a real Cube deployment target with no prior application state:

• Onebox client: v2026.9.7 and checksum-verified v2026.9.8
• target: private host reached through an SSH jump
• application: valid Onebox manifest, unmanaged shared proxy, one PostgreSQL service, no current release
• ob status completes and correctly reports the application as never deployed
• equivalent OpenSSH commands through the same jump complete immediately

Run:

ob -c <generated-config> -v plan --out ob-plan.json

The plan emits:

observing host, pinning images, and staging release
[target] $ if [ -f /var/lib/ob/<app>/backup/state/postgres.lifecycle.json ] ...

and then makes no further progress. It remained blocked for more than five minutes on one attempt and more than one minute on two clean retries. Ctrl-C terminates it; no plan artifact is written. Re-running with v2026.9.8 produces the same behavior.

The application directory does not yet exist, which is the expected first-deploy state. Running a direct ssh -J ... probe for the absent lifecycle path returns missing immediately. Registry images also exist and are readable.

Expected

ob plan should classify the absent lifecycle state as a first deployment, then either produce a plan or return a bounded, actionable refusal (for example missing secret inputs). No remote read should wait indefinitely.

Impact

This blocks the first deployment before an executable plan or approval artifact can be created. The stalled read has no command-level timeout or diagnostic naming which concurrent observation is actually blocked.

Start with the ob plan first-deployment path and the remote read of /var/lib/ob/<app>/backup/state/postgres.lifecycle.json; compare its behavior with the direct ssh -J ... probe described in the reproduction. Confirm that an absent lifecycle state is classified as a first deployment, that the read has bounded failure behavior and diagnostics, and that a plan artifact or actionable refusal is produced.