Stop waiting forever on scans that already ended

[leenk7991]

corgea scan polled until status == "complete", so a scan that ended as incomplete was polled forever — the CI job hung until its own timeout with no indication anything had failed.

• Scan status is classified into completed / failed / running, with incomplete, failed, error, and cancelled all terminal, matched case-insensitively (corgea wait compared against "Complete" and never matched).
• A failed scan prints the reason and each scanner problem, then exits 1, so CI fails loudly.
  • A scan that completes with a scanner missing exits 0 and warns, since the other results are still valid.
• Polling gives up after 4 hours (CORGEA_SCAN_TIMEOUT_SECONDS overrides) rather than burning a job's whole budget on a scan that never reaches a terminal state.
• corgea scan, corgea wait, and corgea upload --wait all share this path.
  • Problem lists are capped at 10 lines with a pointer to the scan page.
• Backward compatible: failed_reason and scan_errors are optional, so responses from servers without the doghouse change still parse and behave as before.

Merge order: doghouse first (the API fields the CLI reads), then fusion (writes the messages doghouse sanitizes), then cli. The CLI tolerates servers without the new fields, so the order is about when the output becomes useful, not about breakage.

Linear ticket

• Fix Maven dependency analysis failures for Maven projects

Test results

Before fix

---

After

[corgea-security]

Automated review risk: 4/5.

The core failure-reporting path breaks when the API returns scan_errors as null. The scan-details fallback URL also mishandles project names containing slashes.

Critical or high-priority changes must be addressed.

Automatic approval was not submitted: automated review found critical or high-priority findings.

[Ibrahimrahhal]

if we check for all scan status why do we need CORGEA_SCAN_TIMEOUT_SECONDS? The issue with this is that we have scans that can take 10 hours or more for big clients. maybe we can set it as 10hours for now and document that clients can override that in the docs

[leenk7991]

if we check for all scan status why do we need CORGEA_SCAN_TIMEOUT_SECONDS? The issue with this is that we have scans that can take 10 hours or more for big clients. maybe we can set it as 10hours for now and document that clients can override that in the docs

done, it's set to 10 hours, and documentation updates in https://github.com/Corgea/docs/pull/303

[corgea-security]

Automated review risk: 2/5.

The diff addresses the existing timeout, null deserialization, and URL-encoding comments with targeted tests. No actionable critical, high-priority, or nitpick findings remain in the supplied diff.

No critical or high-priority changes were found.

Automatic approval was not submitted: changes have been requested.

[juangaitanv]

a stalled status read can exceed CORGEA_SCAN_TIMEOUT_SECONDS because requests use the 150-second client timeout; could we start one deadline before the initial read and cap requests to its remaining time?