docs(infra): document team mkcert CA on vm-gitlab (cross-VM trust)

Add a Team mkcert CA on vm-gitlab subsection to infra/README.md so
the dockerised dev mode scales to a multi-dev team: one shared CA
held on vm-gitlab, public rootCA.pem distributed to each developer's
Windows trust store, R&D Lead mints per-VM certs on vm-gitlab. The
CA private key never leaves vm-gitlab.

The solo flow already in the HTTPS dev-server setup section stays
the entry point for the first dev; this subsection picks up where
that one ends and answers the next question — how a teammate can
browse another dev's VM with a green padlock.

Covers initial CA setup on vm-gitlab, the canonical mkcert per-VM
mint command, onboarding a new dev (rootCA.pem + per-VM cert
delivery + Windows-side import), and operational notes (departures,
CA rotation, per-VM rotation, migration to a future corp-CA cert).

No code changed.

infra/README.md

@@ -270,6 +270,117 @@ Native `nx serve` (WSL / localhost) is **unaffected** — it keeps using the `de
 
 When real DNS + corp-CA-signed certs arrive, the hostname can be reused as-is (Entra registrations are literal strings — they don't care who signs the cert). Drop the cert files back into `.secrets/` and remove the mkcert step.
 
+### Team mkcert CA on `vm-gitlab` — sharing the trust root
+
+The previous section is the **solo flow** (one dev mints their own CA, certs only trusted by their own workstation). It does not let a teammate browse another dev's VM without a certificate warning — every dev has their own private CA, none of which the others trust.
+
+For a multi-dev team the canonical pattern is one shared CA held on `vm-gitlab`. The CA private key (`rootCA-key.pem`) stays on `vm-gitlab` — never copied to any workstation; only the public `rootCA.pem` is distributed to each developer's Windows trust store, and the R&D Lead mints per-VM certs on `vm-gitlab` when a new VM (or new developer) joins. Browsing any dev VM from any workstation then "just works" — green padlock, no warning.
+
+This subsection assumes the per-dev workstation procedure of "HTTPS dev-server setup" above is what every developer will do **once**, with the rootCA.pem they receive from this shared CA.
+
+#### Initial setup on `vm-gitlab` (one-time, by the R&D Lead)
+
+```bash
+# 1. Install mkcert on vm-gitlab (no service to run — mkcert is one-shot).
+sudo curl -fsSL https://dl.filippo.io/mkcert/latest?for=linux/amd64 \
+  -o /usr/local/bin/mkcert
+sudo chmod +x /usr/local/bin/mkcert
+
+# 2. Create the shared CAROOT, root-only.
+sudo mkdir -p /srv/apf-portal/mkcert-ca
+sudo chown root:root /srv/apf-portal/mkcert-ca
+sudo chmod 700 /srv/apf-portal/mkcert-ca
+
+# 3. Generate the CA into that CAROOT. (`-install` here just touches
+#    the local trust store of vm-gitlab — cosmetic for an infra VM,
+#    no harm.)
+sudo CAROOT=/srv/apf-portal/mkcert-ca mkcert -install
+
+# 4. Verify.
+sudo ls -la /srv/apf-portal/mkcert-ca/
+# → rootCA.pem (-rw-r--r--), rootCA-key.pem (-rw-------, root only)
+```
+
+After this, the CA exists and is owned by `root` on `vm-gitlab`. Developers never touch it directly.
+
+#### Minting a cert for a dev VM (R&D Lead, on `vm-gitlab`)
+
+Repeat once per VM hostname (`apf-portal.dev-jg.local`, `apf-portal.dev-vc.local`, `apf-portal.dev.local`, …). Replace `<host>` and the SSH/scp target accordingly:
+
+```bash
+sudo CAROOT=/srv/apf-portal/mkcert-ca mkcert \
+  -key-file /tmp/<host>-tls.key \
+  -cert-file /tmp/<host>-tls.pem \
+  apf-portal.<host>.local
+
+# Sanity check.
+sudo openssl x509 -in /tmp/<host>-tls.pem -noout -subject -issuer
+# subject CN must be apf-portal.<host>.local; issuer the mkcert CA name.
+
+# Ship to the target VM, renaming to the path the `https` Nx serve
+# configuration expects (.secrets/dev-tls.{key,pem}).
+sudo scp /tmp/<host>-tls.key <vm>:~/Works/apf_portal/.secrets/dev-tls.key
+sudo scp /tmp/<host>-tls.pem <vm>:~/Works/apf_portal/.secrets/dev-tls.pem
+
+# Wipe the staging copies.
+sudo rm /tmp/<host>-tls.*
+```
+
+The certificate is good for ~2 years (mkcert default). When it nears expiry, regenerate with the same command and re-`scp` — the dev-server picks up the new files on next restart.
+
+#### Onboarding a new developer
+
+A new teammate needs **three things**: a copy of `rootCA.pem` (public, low-sensitivity), a per-VM cert minted by the R&D Lead, and the same hosts-file + `.env` configuration every dev follows.
+
+**R&D Lead side** — on `vm-gitlab`:
+
+```bash
+# Hand off the public CA cert to the new dev via a secure channel
+# (1Password shared vault, Bitwarden, direct scp). Never plain e-mail.
+sudo cat /srv/apf-portal/mkcert-ca/rootCA.pem
+```
+
+Then mint that dev's per-VM cert (see "Minting a cert for a dev VM" above) and ship it to their VM's `~/Works/apf_portal/.secrets/`.
+
+**New developer side** — on their Windows workstation:
+
+```powershell
+# 1. Install mkcert (only to get the `-install` command — no need to
+#    generate certs on the workstation).
+choco install mkcert -y
+
+# 2. Drop the rootCA.pem they received into the local CAROOT path.
+$caroot = mkcert -CAROOT
+Copy-Item "C:\path\to\rootCA.pem" "$caroot\rootCA.pem"
+# NB: only rootCA.pem — they do NOT receive rootCA-key.pem.
+
+# 3. Register the team CA in their Windows trust store.
+mkcert -install
+# Confirm the Windows security dialog. Their machine now trusts every
+# cert minted by the team CA on vm-gitlab.
+```
+
+Then they:
+
+- Edit `C:\Windows\System32\drivers\etc\hosts` (admin) and add the entries for every VM they want to reach (their own + the others as needed):
+  ```
+  10.100.201.20   apf-portal.dev-vc.local
+  10.100.201.21   apf-portal.dev-jg.local
+  10.100.201.22   apf-portal.dev.local
+  ```
+- Edit `apps/portal-bff/.env` on their VM so the four `ENTRA_*_REDIRECT_URI` values point at `https://apf-portal.<their-host>:{4200,4300}/...` (the matching URIs are already registered Entra-side — no action there).
+- Set `NX_SERVE_CONFIGURATION=https` in `infra/local/.env` on their VM.
+- `./infra/local/dev.sh down && ./infra/local/dev.sh up apps`.
+
+Total onboarding budget: ~5 min of R&D Lead time on `vm-gitlab` (mint + transfer) + ~10 min of work on the new dev's workstation + VM. No SSH access to `vm-gitlab` is granted to developers — only the R&D Lead operates the CA.
+
+#### Operational notes
+
+- **Departures.** mkcert has no CRL; revoking trust on a former dev's machine isn't actionable from the CA side. The risk surface is what that dev could have signed before leaving — and they only ever had the public `rootCA.pem`, never the private key, so they cannot have signed anything in your trust circle. No action required when a dev leaves.
+- **CA rotation.** Rare (audit, suspected compromise, annual hygiene). Regenerate the CA on `vm-gitlab`, re-mint every VM's cert, redistribute the new `rootCA.pem` to each dev. Each dev re-imports + re-`mkcert -install`. No `.env` or Entra change.
+- **Per-VM cert rotation.** Same pattern as initial mint — regenerate, scp, `dev.sh restart portal-shell portal-admin`. No client-side action.
+- **Migration to a corp-signed CA.** When the infra team issues an internal-CA-signed cert (already trusted by every domain-joined workstation, no mkcert step), drop those files into `.secrets/dev-tls.{key,pem}` and remove the team mkcert CA from each dev's trust store. Entra registrations are unchanged — they reference hostname + port, not the issuer.
+
 ### Service endpoints (defaults)
 
 | Service                      | Host port | Purpose                                                                                                                                                                                                                         |