chore: move flaky dependency audits out of lint job

[caitlon]

Greptile Summary

This PR extracts the pip-audit and npm audit steps from the required lint job into a new standalone dependency-audit job, and wraps each audit command in a 3-attempt retry loop to absorb transient registry timeouts. The intent is to prevent a flaky network call from blocking the lint gate and therefore the downstream test jobs.

• The new dependency-audit job is correctly decoupled from lint and from all test jobs, so a registry outage can no longer cascade into a CI blockage.
• The retry logic does not differentiate between a transient network error and an actual vulnerability finding — both cause a non-zero exit — so a real CVE triggers two unnecessary retries and ultimately surfaces under the misleading "failed after 3 attempts (network?)" banner rather than the audit tool's own report.

Confidence Score: 4/5

Safe to merge — the change correctly isolates flaky network calls from the required lint gate, and the overall CI flow remains sound.

The restructuring is straightforward and achieves its goal. The retry loops treat a real vulnerability finding the same as a network error, causing redundant retries and a misleading failure message, but the job still fails correctly when a CVE is present.

The retry logic in the dependency-audit job steps (lines 82-111) is worth a second look regarding how failures are surfaced to the team.

Important Files Changed

Filename	Overview
.github/workflows/ci.yml	Moves pip-audit and npm audit from the lint job into a new independent dependency-audit job with 3-attempt retry loops; the retry logic does not distinguish transient network failures from genuine vulnerability findings, which can produce misleading output but does not affect overall correctness.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
.github/workflows/ci.yml:102-111
**Retry loop can't distinguish network errors from vulnerability findings**

Both `npm audit` and `pip-audit` exit non-zero for *two* distinct reasons: a transient network error and an actual vulnerability finding. The retry loop treats both identically, so when a real CVE is detected the job will silently retry it twice more (burning ~30 s) before finally failing with the misleading banner `npm audit failed after 3 attempts` instead of the audit's own vulnerability report. The `(network?)` hint in the warning will actively mislead anyone trying to diagnose a real security hit.

The same logic applies to the `pip-audit` retry block above (lines 82-89).

_{Reviews (1): Last reviewed commit: "ci: move flaky dependency audits out of ..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

Retry loop can't distinguish network errors from vulnerability findings

Both npm audit and pip-audit exit non-zero for two distinct reasons: a transient network error and an actual vulnerability finding. The retry loop treats both identically, so when a real CVE is detected the job will silently retry it twice more (burning ~30 s) before finally failing with the misleading banner npm audit failed after 3 attempts instead of the audit's own vulnerability report. The (network?) hint in the warning will actively mislead anyone trying to diagnose a real security hit.

The same logic applies to the pip-audit retry block above (lines 82-89).

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/ci.yml
Line: 102-111

Comment:
**Retry loop can't distinguish network errors from vulnerability findings**

Both `npm audit` and `pip-audit` exit non-zero for *two* distinct reasons: a transient network error and an actual vulnerability finding. The retry loop treats both identically, so when a real CVE is detected the job will silently retry it twice more (burning ~30 s) before finally failing with the misleading banner `npm audit failed after 3 attempts` instead of the audit's own vulnerability report. The `(network?)` hint in the warning will actively mislead anyone trying to diagnose a real security hit.

The same logic applies to the `pip-audit` retry block above (lines 82-89).

How can I resolve this? If you propose a fix, please make it concise.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud