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/security-scheduled.yml

@@ -14,6 +14,13 @@ on:
 jobs:
   full-tree-scan:
     runs-on: [self-hosted, on-prem]
+    # Step ordering mirrors ci.yml: scanners run before `pnpm install`
+    # so the working tree is not polluted with node_modules content
+    # (READMEs / fixtures of upstream packages contain demo
+    # secrets that gitleaks false-positives on by the hundreds).
+    # The deep-history gitleaks scan here doesn't strictly need it
+    # (history doesn't contain node_modules), but consistency with
+    # ci.yml keeps the two workflows reading the same way.
     steps:
       # fetch-depth: 0 → full history. The per-PR gitleaks scan is
       # shallow + working-tree-only; this scheduled job is where we
@@ -26,8 +33,6 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version-file: '.nvmrc'
-      - run: pnpm install --frozen-lockfile
-      - run: pnpm audit
       # Full-tree Trivy (no skip-dirs, no severity filter — the per-PR
       # gate filters by severity for speed; this run wants the full
       # surface for the security feed). Manual install + curl, same
@@ -69,6 +74,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 audit
 
   lighthouse-prod:
     # Skipped silently if the prod URL hasn't been configured yet.