Initial commit: plugin skeleton, compiles against CoreDNS 1.14.3

Sets up the package layout for a CoreDNS plugin that will accept RFC 2136
dynamic updates with TSIG authentication, primarily targeting self-hosted
ACME DNS-01 cert automation.

What this commit gives us:
- go.mod against coredns/caddy v1.1.4, coredns/coredns v1.14.3, miekg/dns v1.1.72
- plugin.go: RFC2136 struct + Handler interface (ServeDNS is pass-through)
- setup.go: init() registration + Corefile parser (skeleton — recognizes
  tsig-key, ttl, persist directives but doesn't yet wire them)
- README.md, .gitignore

go build ./... clean. No tests yet — those come with Phase 1.2 alongside
the actual UPDATE handler and in-memory store.

Plan: ~/.claude/plans/dood-does-coredns-offer-enumerated-piglet.md

README.md

@@ -0,0 +1,76 @@
+# coredns-rfc2136
+
+A [CoreDNS](https://coredns.io) plugin that accepts **RFC 2136 dynamic DNS
+updates** (TSIG-authenticated), filling a gap in the official plugin set.
+
+CoreDNS as-shipped has no plugin for accepting dynamic updates — its
+plugin model treats authoritative data as read-only (loaded from `auto`,
+`file`, `secondary`, etc.). This plugin adds the missing piece.
+
+## Primary use case: self-hosted ACME DNS-01
+
+The motivating problem: automate Let's Encrypt cert issuance for many
+domains without depending on registrar APIs (Vultr/Route53/Cloudflare).
+The architecture:
+
+```
+_acme-challenge.example.com  CNAME  <uuid>.auth.supported.systems
+                                      │
+                                      │ delegated NS to your CoreDNS host
+                                      ▼
+                              CoreDNS + rfc2136 plugin
+                                      │
+                                      │ accepts TSIG UPDATEs from Caddy
+                                      │ (caddy-dns/rfc2136) or any other
+                                      │ ACME client
+                                      ▼
+                                  Let's Encrypt validates
+```
+
+One-time per protected domain: add a `CNAME` glue line in your static
+zones. After that, all cert issuance + renewal happens via UPDATE
+messages — zero static zone-file churn.
+
+## Status
+
+**Phase 1 (skeleton)**: compiles, registers with CoreDNS, parses the
+Corefile directive. Does not yet handle UPDATE messages or serve any
+records. ServeDNS is a pass-through. See `phases.md` for the roadmap.
+
+## Configuration
+
+```
+rfc2136 <zone> [<zone>...] {
+    tsig-key <key-name> <algorithm> <base64-secret>
+    ttl <seconds>
+    persist <path>
+}
+```
+
+Example:
+
+```
+.:53 auth.example.com {
+    rfc2136 auth.example.com {
+        tsig-key acme-key. hmac-sha256 BASE64SECRET==
+        ttl 60
+    }
+    errors
+    log
+}
+```
+
+## Building
+
+This plugin is consumed by a custom CoreDNS build via `plugin.cfg`:
+
+```
+# In CoreDNS source's plugin.cfg, BEFORE the `cache` plugin:
+rfc2136:git.supportedsystems.net/rpm/coredns-rfc2136
+```
+
+Then `go get git.supportedsystems.net/rpm/coredns-rfc2136 && make`.
+
+## License
+
+MIT (TODO: add LICENSE file).