go-milter: build it patched not to keep every header

The security documentation's last open item of panel-dkim-signing (the
owner's decision, 2026-10-16): go-milter v0.4.1 added every header of a
session to a map of its own, emptied only on ABORT, and handed it to
Headers - which no milter of the panel reads. Postfix bounds one header,
not their number, so a message of nothing but headers up to the message
size limit was held whole by the library in the sender check, the signer
and the journal milter on 465/587 and in the inbound journal milter on port
25, where strangers send; the signer's 1 MiB refusal came after it was all
in.

third_party/go-milter is v0.4.1 from the module cache (BSD 2-Clause,
LICENSE kept) with session.go changed: CodeHeader hands the header to
Header and keeps nothing, CodeEOH hands Headers an empty map. PATCHES.md
says what and why, and how to take a new upstream version. go.mod replaces
the module with it; the Dockerfile copies third_party before "go mod
download". TestTheLibraryKeepsNoHeaders holds it through the library's own
client over two messages of one connection. Comments, security.md (the
accepted risk becomes a note), development.md's library table, the plan and
CHANGELOG follow.

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

CHANGELOG.md

@@ -55,6 +55,11 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); version
   it as quoted-printable for a server that does not announce 8BITMIME, after
   it was signed; `disable_mime_output_conversion=yes` now delivers it as
   signed. OpenDKIM's signatures were exposed to this too.
+- **A message of nothing but headers was held whole by every milter.** The
+  milter library (go-milter v0.4.1) kept each header of a message in a map
+  of its own that no milter of the panel read - up to the message size
+  limit, on port 25 from strangers too. The panel builds it patched not to
+  (`third_party/go-milter`).
 - **A rotation of `mail.log` due at the container's start logged an error.**
   It runs before Postfix does, and its `postfix reload` failed ("the Postfix
   mail system is not running"); nothing was lost - the Postfix starting