CI has no permissions block and pins actions to mutable tags

**Good news first, since this is the usual place to find trouble:** there is **no `pull_request_target`** anywhere, and **no `${{ github.event.* }}` interpolation in any `run:` block** — so no script-injection sink exists. All actions are first-party `actions/*`. The workflow-level `SECRET_KEY`/`DB_PASS` values are clearly-labelled CI-only fallbacks, not real secrets.

What remains:
- `backend-quality.yml` has **no `permissions:` block**, so the job inherits the repository default `GITHUB_TOKEN` scope — `write-all` on older repo settings. It needs `contents: read` only. Fork PRs get a read-only token automatically; same-repo PR branches do not.
- Actions are pinned to **mutable major tags**, not commit SHAs. A compromised `actions/checkout` v4 tag executes in a job holding the repo token.
- No job runs a container build, a `docker compose config` validation, or `nginx -t` over the templates — which is precisely why `ssl on;` has survived.

**Fix:** add `permissions: {contents: read}`; pin actions to SHAs with Dependabot to bump them; add a config-validation job — and verify it *fails* by leaving `ssl on;` in temporarily, before trusting it.

---

**Evidence**

```
.github/workflows/backend-quality.yml:4,14-46,75,147
```

- Verified against: `origin/master 44ca47e (2026-07-25)`
- Verdict: **CONFIRMED**

Start with .github/workflows/backend-quality.yml at the cited lines, inspect the existing action references and workflow permissions, then locate the nginx templates and compose configuration used by CI. Done means contents-only permissions, SHA-pinned actions with Dependabot updates, and a validation job that catches the temporary ssl on; failure while checking the relevant configs.

Written by the indexing model from the issue text.