fix(ci): run scanners before pnpm install to avoid node_modules false positives (#51)

## Summary
First successful gitleaks run flagged **381 "leaks"** — all inside `node_modules/` and `.pnpm-store/`, populated by the `pnpm install --frozen-lockfile` step that ran earlier in the job. Upstream npm packages routinely embed demo RSA keys / fake API tokens in their READMEs and test fixtures, and gitleaks correctly (by its rules) flags them.

Same class of false-positive Trivy hit in #49 — solved there by `--scanners vuln`. Here, the cleanest solution is **reordering**: run the scanners *before* `pnpm install`, so the working tree contains only our committed source.

- **Trivy** scans `pnpm-lock.yaml` (committed) — doesn't need install.
- **Gitleaks** scans the working tree (`--no-git --source .` in ci.yml) — doesn't need install.
- **pnpm audit** reads `pnpm-lock.yaml` against the advisory DB — also doesn't need install. The install before audit remains for the workspace-integrity sanity check.

The ordering rationale is committed as a comment at the top of each job's `steps:` block, so a future contributor doesn't innocently shuffle the steps and re-flood the gate with FPs.

Same reordering applied to `.gitea/workflows/security-scheduled.yml` for consistency, even though its deep-history gitleaks scan doesn't suffer this issue (`node_modules` is `.gitignore`d from day one — never in history).

## Test plan
- [ ] `scan` job goes green end-to-end on this PR — gitleaks reports 0 leaks (or only real ones from our source, none expected).
- [ ] On `push` to main post-merge, scan stays green.
- [ ] Trigger `security-scheduled` manually before next Monday's cron to verify the same ordering doesn't break the deep scan.

## After this PR
With #43 (TS/ESLint reverts), #45 (Trivy install), #49 (Trivy `--scanners vuln`), #50 (gitleaks install), and now this — every gate of the CI pipeline should be green end-to-end. Phase-1 CI bring-up is then complete and we can move to **A — local infra recipe** (Postgres + Redis + OTel Collector).

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #51

.gitea/workflows/ci.yml

@@ -55,14 +55,22 @@ jobs:
 
   scan:
     runs-on: [self-hosted, on-prem]
+    # Step ordering matters here: Trivy and gitleaks BOTH run before
+    # `pnpm install`. Reason: gitleaks scans the working tree
+    # (`--no-git --source .`), and after install, `node_modules/`
+    # and `.pnpm-store/` are full of upstream packages whose READMEs
+    # and test fixtures contain demo RSA keys / fake API tokens —
+    # gitleaks then false-positives on them by the hundreds (caught
+    # the hard way: 381 hits on the first run). Trivy reads
+    # `pnpm-lock.yaml` for its vuln scan, not `node_modules`, so it
+    # also doesn't need install. `pnpm ci:audit` does the same — it
+    # queries the advisory DB against the lockfile.
     steps:
       - uses: actions/checkout@v6
       - uses: pnpm/action-setup@v6
       - uses: actions/setup-node@v6
         with:
           node-version-file: '.nvmrc'
-      - run: pnpm install --frozen-lockfile
-      - run: pnpm ci:audit
       # Dependency vulnerability scan. Trivy is a Go binary, not an npm
       # package, so it cannot live in package.json scripts as cleanly
       # as audit/lint do.
@@ -150,6 +158,11 @@ jobs:
             --source . \
             --redact \
             --exit-code 1
+      # npm-advisory check (against pnpm-lock.yaml). Run last so
+      # `pnpm install` does not pollute the working tree before the
+      # scanners above.
+      - run: pnpm install --frozen-lockfile
+      - run: pnpm ci:audit
 
   commits:
     # PRs opened by Renovate (apf-portal-bot) carry commit messages