Wait for public staging API readiness

[suguanYang]

Summary

• replace the staging start workflow's one-shot public health request with a bounded readiness gate
• retry transient ALB 502/503 responses every ten seconds for up to five minutes
• record cold-start duration and report startup success only after the public endpoint returns successfully
• add contracts for API ordering, bounded retries, and readiness timing

Evidence

The corrected worker-health workflow reached API desired/running/pending 1/1/0 but failed its immediate health request with HTTP 502: run 31895113244. Shortly afterward, live target-group readback showed the API target as healthy, and the same public /health URL returned HTTP 200. The API health endpoint itself is an in-process response and does not query Neon.

The AWS CLI services-stable waiter verifies ECS deployment/running counts, not public load-balancer route readiness. We therefore poll the public endpoint within a hard deadline before declaring startup successful.

This is the bounded API-readiness correction for Ontos-AI/knowhere-api-infra#30. It does not create resources or dispatch another AWS operation.

Verification

• uv run pytest deploy/ecs -q — 16 passed
• uv run --group lint ruff check deploy/ecs/test_manage_staging_workflow.py deploy/ecs/render_task_definitions.py deploy/ecs/test_render_task_definitions.py
• uv run --group typecheck pyright deploy/ecs/test_manage_staging_workflow.py
• workflow YAML parsing and embedded Bash syntax check
• git diff --check
• standards review: no findings
• spec review: no findings