docs: clear shipped plans and closed work out of the documents

Owner, 2026-10-18: "Надо почистить документы от устаревшего и сделанного."

- Deleted, shipped: plans/delivery-log-storage, from-header-binding,
  inbound-antispam-panel, inbound-upstream-result, panel-dkim-signing,
  panel-notifications, and the own-mta-builds analysis (its three rows
  shipped as 2.6.1, 2.7.0, 2.8.0). What outlived them moved first: when a
  filter-list counter is worth a migration, and the notifications' "when"
  table, into architecture.md; the sender check's own-process trigger into
  security.md. Code comments that cited them point at architecture.md or
  security.md; CHANGELOG keeps their names, unlinked.
- Kept, marked closed: audit-2026-10-12, assumptions-2026-10-14 and
  security-audit-2026-10-17 - the code cites their finding ids in 50-84
  files. Their file:line refs are of the tree each audited.
- roadmap.md: open work only - stage H of the security audit (the owner's),
  go-milter-upstream (the owner posts), and queue-table, which the
  redesign left undecided and only its own shipped section still named;
  Dropped and Ideas as they were. 2.x versioning instead of 1.x.
- development.md: the 47-row planned-version-cuts table (history, in the
  CHANGELOG) gone; a stage's last step now removes its roadmap item and
  plan. Docs map lists the closed audits.
- panel-redesign.md: the done checklist out; Room for roadmap items says
  which drawn screens are unbuilt and why.
- Stale facts fixed: schema-migrations.md and architecture.md at schema 14
  (0013's users columns and user_links, 0014's secure TLS mode);
  security.md's accepted risk "profile saved without the password" - the
  e-mail asks for it since 2.14.0.

Tests: go build, go vet; go test of cmd and the touched internal packages
pass except logtail's three Windows-bound rotation tests (rename of an open
file; CI is Linux). Only comments changed in Go.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/plans/inbound-quarantine.md

@@ -1,8 +1,8 @@
 # Plan: inbound-quarantine
 
 **Status:** an idea to think about, not on the roadmap (owner, 2026-10-12) — design TBD; needs explicit agreement before any code  
-**Version:** TBD (`1.x` MINOR if opt-in and backward-compatible; may warrant `2.x`
-if it changes inbound storage or backup contract).
+**Version:** TBD (a 2.x MINOR if opt-in; a major only if it breaks the
+inbound storage or backup contract).
 
 ---
 
@@ -17,8 +17,8 @@ so we can compare approaches before committing.
 
 ## Why it is separate from inbound-antispam-panel
 
-[inbound-antispam-panel.md](inbound-antispam-panel.md) covers **metadata**
-(journal + lists). Quarantine implies **storing message bodies** (or a durable
+inbound-antispam-panel (shipped `2.1.0`; [architecture.md](../architecture.md)
+§ Mail path) covers **metadata** (journal + lists). Quarantine implies **storing message bodies** (or a durable
 reference to them) under `/data`, retention, release workflow, and a wider
 attack/backup surface — closer to "mini-mailbox" than pure relay.
 
@@ -68,9 +68,7 @@ to the upstream, 14 days, headers only in the panel); it does not settle them.
 
 - Inbound relay, shipped in `[1.4.0]` — as built in
   [architecture.md](../architecture.md) § Mail path.
-- Sensible to decide **after** or **alongside**
-  [inbound-antispam-panel.md](inbound-antispam-panel.md) (journal/lists), but
-  not blocked on it for design discussion.
+- Builds on inbound-antispam-panel (journal and lists, shipped `2.1.0`).
 
 ## Done when (placeholder)