docs: Propose one writer per zone for DNS records

[vvoytovych]

What I noticed

Two record sets can claim the same name in a zone. The usual pair is a user's own record and the one Gateway DNS creates for the same hostname. Since v0.7.0 the agent writes one record set at a time, so it never sees both claims and cannot choose between them:

• Both write, and both report Programmed=True. #83 found such pairs in production. In one, the two point at different targets, and the name answers with whichever wrote last.
• When one lets the name go, the agent deletes the name, although the other still claims it. The name goes silent, and no alert fires (#188).
• The losing record set no longer reports NotOwner, so DNSRecordRejected cannot fire (runbook).

The admission webhook refuses a second claim, but it fails open by design and cannot see older pairs. So the agent still has to decide.

What we plan

The agent writes one zone at a time. It reads every record set of the zone, picks one holder per name by the rule our record ownership document already states (the oldest claim wins, as in Gateway API), and writes only the difference.

We get there in small steps. Each step is its own release. Each is verified locally (unit tests, integration tests against PowerDNS, and the end-to-end suites on three clusters) and then on staging, before it reaches production. The release before it is the rollback.

Step	Does it change what DNS serves?
The owner-name rule in its own package (#198)	no
A separate fix, first because it is a live defect: stop lowering zones' SOA serials (#101)	the serial only
Remove the duplicate pairs in production by hand, with their owners	those names only
One election function for the webhook and the agent	no
The per-zone writer, load-tested at production scale first	only where a name is claimed twice, and leftovers
Remove what it makes unused, with the old reconciler (#86)	no

What it gives us

• A released name keeps answering. It goes only when nobody claims it.
• A record set that loses a name says so again, and DNSRecordRejected works again.
• One place decides who holds a name. No locks, no special release path, and a simpler backend interface (#88).
• Leftover records of past failures are removed, within a deletion limit.
• About 1,350 lines of unused code and its tests go.

How it fits where we are going

• It is a step toward your point on #171: the control plane programs the data plane, zone by zone, from what is declared. The ownership notes stay for now, because they are the only mark of what the agent may delete. They can go once a zone is fully declared.
• Each zone keeps one writer for its records. That fits the federation and zone transfer plans.
• The agent stays additive outside the records it owns, as the datum.net DNS as code plan requires.
• It is load-tested against the 60-second target of the convergence SLOs.
• It follows common DNS practice: DNSControl and octoDNS build a zone from what is declared and apply the difference, and we take octoDNS's deletion limit.

Not in this plan: deleting records we did not write, and replacing the ownership notes.

Take a look, and let me know if you have any major concerns. Thanks.

[ecv]

oh!