docs(setup): make fail2ban opt-in in 70-hardening.sh (#222)

## Summary

Follow-up on [#220](#220) / [#221](#221). Makes fail2ban **opt-in** in [`70-hardening.sh`](docs/setup/scripts/70-hardening.sh) instead of installing it unconditionally.

Reasoning: some corp environments already ship brute-force protection at the network layer (ACL / corp firewall / appliance) — fail2ban on the host then becomes redundant and can be the wrong layer to debug from when a rule misfires. The other three hardening steps (UFW enable, sshd lockdown) were already prompt-gated; fail2ban was the odd one out.

## What lands

| File | Change |
| --- | --- |
| `docs/setup/scripts/70-hardening.sh` | fail2ban block restructured into three branches: (1) already running → skip; (2) installed but stopped → prompt to enable+start; (3) not installed → prompt to install+enable+start. Each "no" path logs `↪ skip (user choice)` so re-runs don't repeatedly nag if the dev has already declined. |
| `docs/setup/01-dev-debian-vm-setup.md` | Table row for `70-hardening.sh` clarified — each sub-step's prompt posture is now visible: UFW prompts before enabling, fail2ban prompts before installing, sshd hardening prompts before applying. `unattended-upgrades` is the only one applied unconditionally. |
| `docs/setup/README.md` | Same descriptor adjustment. |

## Test plan

- [ ] On a fresh Debian VM with no fail2ban installed, run `70-hardening.sh`, decline the fail2ban prompt → script continues, fail2ban not installed, no service started.
- [ ] On the same VM, re-run `70-hardening.sh` → the fail2ban branch prompts again (the dev may have changed their mind); declining again produces the same `↪ skip (user choice)` result.
- [ ] On a VM where fail2ban is pre-installed but stopped (rare, but possible if infra rolled it back), the script offers to start it without re-installing.
- [x] `pnpm exec prettier --check` clean on the touched files.
- [x] `bash -n docs/setup/scripts/70-hardening.sh` (syntax check) clean.

---------

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

docs/setup/scripts/70-hardening.sh

@@ -47,13 +47,29 @@ EOF
   ok "unattended-upgrades enabled."
 fi
 
-# ─── 3. fail2ban ───────────────────────────────────────────────────────
-apt_install fail2ban
+# ─── 3. fail2ban (opt-in) ──────────────────────────────────────────────
+# Some VMs already ship with infra-managed brute-force protection at the
+# network layer (corp firewall, ACLs, etc.). In that case fail2ban on the
+# host is redundant — and its presence can be the wrong layer to debug
+# from when a rule misfires. Make it a deliberate choice instead of
+# imposing it.
 if systemctl is-active fail2ban.service >/dev/null 2>&1; then
   skip "fail2ban already running."
+elif dpkg -s fail2ban >/dev/null 2>&1; then
+  if confirm "fail2ban is installed but not running. Enable + start it now?"; then
+    sudo systemctl enable --now fail2ban.service
+    ok "fail2ban started + enabled at boot."
+  else
+    skip "fail2ban left stopped (user choice)."
+  fi
 else
-  sudo systemctl enable --now fail2ban.service
-  ok "fail2ban started + enabled at boot."
+  if confirm "Install + enable fail2ban (SSH brute-force protection)?"; then
+    apt_install fail2ban
+    sudo systemctl enable --now fail2ban.service
+    ok "fail2ban installed + started + enabled at boot."
+  else
+    skip "fail2ban not installed (user choice)."
+  fi
 fi
 
 # ─── 4. sshd hardening ────────────────────────────────────────────────