Retry 404 when polling scan status instead of failing the wait

[Ibrahimrahhal]

Summary

If corgea scan (or corgea wait) successfully starts/finds a scan and then a status poll returns 404, the CLI used to exit 1 immediately. That looks like the scan failed in CI (Scan exited with code: 1) even though the scan is often still running in the cloud — typically replica lag right after upload.

This change:

• Retries 404 on status polls for 90 seconds (same window as the HTTP retry budget), then gives up if the scan still is not visible
• Retries 429/5xx and transport errors until the wait budget expires, matching the blocking-rules wait
• Fails fast on 401/403 (auth is actually broken)
• Words a missed status read as a status-check failure, not “the scan did not complete”

A scan that actually ends in incomplete / failed still prints Scan <id> did not complete. with failed_reason / scanner errors and exits 1.

Test plan

• Unit: 404 retries until grace expires; 5xx/transport retry; 401/403 fail-fast; status-check copy is not a scan-failure
• E2E corgea wait: processing → 404 → complete succeeds
• E2E: 401 during poll exits quickly and is not worded as a scan failure
• E2E: persistent 404s expire as a timeout (Stopped waiting / not found), not did not complete
• ./harness check on this branch (842 tests passed)