bind/README: applying changes needs both master and slave nodes

The slave's bw-managed zone files are rendered from the master's
metadata at slave-apply time. Changing a record on the master only
publishes once both bw apply runs are done. The left4me-integration
session burned ~20 minutes assuming bw apply on htz.mails would
propagate to ovh.secondary via bind's own AXFR; it doesn't, because
bw verify measures the on-disk file, not the running zone.

Frame as the workflow rule rather than the absolute "not AXFR"
claim — the bundle does set type slave; in named.conf.local, but
that's orthogonal to the practical apply-both rule.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

bundles/bind/README.md

@@ -0,0 +1,30 @@
+# bind
+
+Authoritative DNS — primary plus optional `bind/master_node` slaves.
+
+## Applying changes needs both nodes
+
+The slave's bw-managed zone files are rendered from the master's
+metadata at slave-apply time (see `bundles/bind/items.py:100`). When
+you change a record on the master (adding a `letsencrypt/domains`
+entry, a new vhost, etc.), the change is only published once you
+apply BOTH:
+
+```sh
+bw apply htz.mails        # primary (where the source records live)
+bw apply ovh.secondary    # secondary (renders its own zone files)
+```
+
+Until both have been applied, `bw verify ovh.secondary` will show
+stale zones and consumers that hit the secondary (Let's Encrypt's
+secondary-region validators in particular) will see NXDOMAIN. Even
+though the slave's named.conf.local declares `type slave;`, don't
+rely on bind's own AXFR catching up — the bw-rendered file on disk
+is what `bw verify` measures.
+
+## See also
+
+- `bundles/bind-acme/` — the in-house ACME-update receiver.
+- `bundles/letsencrypt/README.md` — DNS-01 prerequisites and the
+  negative-cache penalty (the most common operational consequence
+  of forgetting to apply the secondary).