Wait for readiness before bootstrap app jobs

[rgjordana]

Why this is useful

Bootstrap installs run while FastAPI is still completing startup, but the app-job runner needs the backend to mint its scoped credential and provide its job context. A first initialization job could therefore exit before the backend was ready, leaving an app empty until its next scheduled run.

Approach

• wait for the existing /api/ready contract only when an initialization job was launched by bootstrap
• start the normal supervised job flow once the backend is ready
• leave manual and scheduled job launches unchanged

Why this approach

This uses the platform's existing readiness boundary and fixes the specific ordering dependency where it occurs. It avoids making app installation depend on a guessed delay and keeps normal jobs fast.

Alternatives considered

• A persistent job queue with lifecycle records and retries would solve broader job-management problems, but adds a second scheduler and state model that this single startup-ordering issue does not need.
• Generic retries or a fixed delay would blur a temporary startup dependency with permanent configuration failures and make the real failure harder to diagnose.

Testing

• python3 -m py_compile backend/app/app_jobs.py backend/app/install.py backend/scripts/app-job-runner.py
• pytest -q tests/test_app_jobs.py -k 'not job_context and not job_token'
• pytest -q tests/test_bootstrap.py

[hamzamerzic]

The readiness boundary is the right fix, but the bootstrap gate currently never activates. In install_from_manifest, source is overwritten with Path(app.source_dir) immediately before wait_for_ready = source == "bootstrap", so the comparison is always false and bootstrap jobs still launch without --wait-for-ready. Please preserve the install-source value before converting the app path (or give the two concepts distinct names), and add an install-path test that proves a bootstrap invocation calls launch_app_job(..., wait_for_ready=True) while an interactive install remains false.

[hamzamerzic]

Reviewed and superseded by the corrected readiness implementation in #283, now merged to main through #304. The original install-source PATH assignment was overwritten before the gate could activate; the integrated version preserves the intended readiness behavior without that defect. Thanks, Ricardo.