docs: Phase 14 — Last reviewed line sweep across docs/

Per Phase 1 audit at cowork/docs-overhaul-phase-1-audit-2026-05-04/.
Adds a `> Last reviewed: 2026-05-05` line right after the H1 heading
of every doc that didn't already have one (41 files).

This dates the freshness clock for the future Phase 4 per-doc review.
The discipline going forward: when a doc's content gets a meaningful
edit, bump the date. When the date gets old (e.g., >6 months), the
doc earns a freshness-review pass.

Mechanical insertion via awk one-liner, applied to every docs/*.md
that didn't already match `grep -q 'Last reviewed:'`. Files that
already carried the line from earlier Phase 2 work (the navigation
index, the new connector docs, the new SCEP server / legacy-clients-
TLS-1.2 / release-verification docs, and the 5 per-connector deep
dives) were skipped to avoid duplicate insertion.

Net: every doc in docs/ now has a Last reviewed line.

docs/migration/acme-from-caddy.md

@@ -1,5 +1,7 @@
 # Caddy Integration Walkthrough
 
+> Last reviewed: 2026-05-05
+
 > **Use this walkthrough when** you're already running Caddy 2.7+ and
 > want it to ACME-issue from certctl (your internal CA, your private
 > PKI, or a local sub-CA chained under an enterprise root) instead of

docs/migration/acme-from-cert-manager.md

@@ -1,5 +1,7 @@
 # cert-manager Integration Walkthrough
 
+> Last reviewed: 2026-05-05
+
 > **Use this walkthrough when** you're already running cert-manager
 > 1.15+ in Kubernetes and want it to issue certs from certctl (your
 > internal CA, your private PKI, or a local sub-CA chained under an

docs/migration/acme-from-traefik.md

@@ -1,5 +1,7 @@
 # Traefik Integration Walkthrough
 
+> Last reviewed: 2026-05-05
+
 > **Use this walkthrough when** you're already running Traefik 3.0+
 > (Kubernetes or VM) and want it to ACME-issue from certctl (your
 > internal CA, your private PKI, or a local sub-CA chained under an

docs/migration/cert-manager-coexistence.md

@@ -1,5 +1,7 @@
 # certctl for cert-manager Users
 
+> Last reviewed: 2026-05-05
+
 You run cert-manager inside Kubernetes and it works well for in-cluster certificates. But you also have VMs, bare-metal servers, network appliances, and legacy systems outside the cluster. cert-manager can't reach those. This guide shows how certctl complements cert-manager to give you unified certificate visibility and automation across your entire infrastructure.
 
 ## Not a Replacement

docs/migration/from-acmesh.md

@@ -1,5 +1,7 @@
 # Migrate from acme.sh to certctl
 
+> Last reviewed: 2026-05-05
+
 You use acme.sh to automate Let's Encrypt renewal across multiple servers. It works — but without centralized visibility, deployment verification, or policy enforcement.
 
 This guide walks through moving your acme.sh workload to certctl while keeping your existing DNS provider setup.

docs/migration/from-certbot.md

@@ -1,5 +1,7 @@
 # Migrating from Certbot to certctl
 
+> Last reviewed: 2026-05-05
+
 You have 50 Let's Encrypt certificates across 10 servers, managed by a mix of Certbot cron jobs and manual renewals. Certbot handles issuance, but you lack inventory visibility, centralized alerting, and audit trails. This guide walks you through moving to certctl while keeping your existing certificates and ACME account.
 
 ## Why Migrate