Fix Lume SSH readiness detection

[jmcte]

Summary

• Reject Lume SSH probe output when deciding whether a newly cloned macOS slot is ready.
• Prevent a zero-exit no IP address response from starting guest bootstrap before SSH is usable.

Governing Issue

Refs OMT-Global/lattice#709.

Validation

• bash -n scripts/lume/lib.sh scripts/lume/run-slot.sh scripts/lume/create-slot.sh
• Dependency-free probe harness: silent success returns 0; a zero-exit Lume no IP address response returns 1 and logs the retry.
• git diff --check
• pnpm exec vitest run test/lume-scripts.test.ts — unavailable because this clean worktree has no Vitest and the lockfile-pinned pnpm install --frozen-lockfile stopped on package-signature verification. The install was not bypassed.

Bootstrap Governance

• No secrets, credentials, or runtime environment files are included.
• The change preserves existing Lume labels and runner-group policy.

Merge Automation

• Independent review and required CI are pending before merge.

Notes

• The controller will be deployed under the explicit Lattice CI-repair authorization to unblock currently queued native checks, then Lattice #748 will be rerun for end-to-end confirmation.

[athena-omt]

Reviewed current head 57e20fb. The readiness path now requires both a zero exit status and empty Lume SSH probe output, so the zero-exit “no IP address” response remains in the retry loop before guest bootstrap. I verified the run-slot call path and added regression coverage. Local shell syntax and diff checks passed; a dependency-free probe confirmed silent success returns 0 and the false-ready response returns 1. The isolated worktree lacks Vitest, but fresh CI test and Lume macOS contract checks are successful. Approved.