Use `npm ci` instead of `npm install` in CI and deploy workflows

## Summary

Every workflow that installs dependencies runs `npm install`. It should run `npm ci`, so that CI and the deploy servers install exactly the tree recorded in `package-lock.json`.

## Why this matters

`npm install` is allowed to resolve newer versions inside the declared semver ranges and to **rewrite `package-lock.json` in place**. Two consequences:

- The CI test job can pass against a dependency tree that is not the one reviewed and approved in the PR.
- The deploy servers can install a tree that was never tested anywhere.

`npm ci` installs the lockfile exactly, never writes to it, and fails loudly if `package.json` and `package-lock.json` have drifted apart.

This surfaced while reviewing #293, which curates the dependency set so that `npm-check` and `npm audit` are both clean. That work only holds if the lockfile is what actually gets installed.

## Affected lines

| File | Line | Current |
|------|------|---------|
| `.github/workflows/cd_dev.yaml` | 29 | `run: npm install` (test job) |
| `.github/workflows/cd_dev.yaml` | 59 | `npm install` (deploy step) |
| `.github/workflows/cd_prod.yaml` | 31 | `run: npm install` (test job) |
| `.github/workflows/cd_prod.yaml` | 58 | `npm install` (deploy step) |

## Proposed change

Test jobs:

```yaml
- name: Install dependencies
run: npm ci
- name: Generate coverage report
run: npm run coverage:ci
```

Deploy steps: `npm ci`. Worth considering `npm ci --omit=dev` on the deploy steps as well, since a bare install currently puts `c8`, `supertest`, `yargs`, `glob`, and the rest of the test tooling into production `node_modules`. That is a related but separable concern — happy to split it into its own issue if preferred.

## Notes

- The lockfile is already `ci`-ready. Verified on the `8-24-26-packages` branch: `npm ci` in a clean directory installs 169 packages and reports 0 vulnerabilities.
- `npm ci` requires `package-lock.json` to exist and to agree with `package.json`. Both hold today.
- `npm ci` deletes `node_modules` before installing. On the self-hosted deploy runners (`vlcdhp02`, `vlcdhprdp02`) this makes installs slower but reproducible. The `actions/cache@v4` step already in both workflows should absorb most of that cost on the GitHub-hosted test jobs.

## Acceptance criteria

- [ ] `cd_dev.yaml` and `cd_prod.yaml` use `npm ci` in the test jobs
- [ ] `cd_dev.yaml` and `cd_prod.yaml` use `npm ci` in the deploy steps
- [ ] A CI run completes with `package-lock.json` unmodified afterward
- [ ] Dev deploy verified healthy before the same change reaches prod

Inizia con i quattro passaggi di installazione interessati in .github/workflows/cd_dev.yaml e .github/workflows/cd_prod.yaml, quindi esamina i job di test e deploy circostanti. Esegui i workflow o valida npm ci in una directory pulita e conferma che entrambi i workflow vengano completati con package-lock.json invariato e che il deploy dev sia in buone condizioni prima della produzione.

Scritto dal modello di indicizzazione a partire dal testo della issue.