Land the reconcile rework and hold prod until duplicates are cleared

[ecv]

Summary

Tomáš Boros (@fr6nco) has finished his changes on #82 and reports them backward compatible, but he could not take them to staging and is out until Monday 24 August 2026. Staging still runs a branch build of #79, so a merge to main changes nothing there until that pin is reverted.

Warning

Do not roll this to production until #83 is cleared, because the new writer replaces a whole record set from one object's spec and six owner keys in production are claimed by two record sets each.

What needs to happen

Each step blocks the next, and the last one is also blocked by the manual cleanup.

1. Land the class and reconcile rework on main #96
2. Point staging back at main builds #97
3. Prove the reconcile rework survives an upgrade on staging #98
4. Production has duplicate DNS record sets #83
5. Deploy the reconcile rework to production #99

Acceptance criteria

• Staging runs a build from main, not from a branch.
• Zones and record sets that existed before the upgrade still resolve, still report their real programmed state, and none sit in Terminating.
• No owner key in production is claimed by two record sets.
• Production runs the merged build.

Warnings

The review findings that were accepted rather than fixed are already filed as #84, #86, #87, #88, #89, #90, #91, #92 and #93, and none of them block this rollout. The two the author named for a later cycle are making the record type and the zone reference immutable, and adding a validating webhook so a duplicate claim cannot enter the system at all.

Related to #58, #59, #79, #82, #83

[ecv]

The rework in #82 merged on 26 August and shipped in v0.7.0. Steps #96, #97 and #98 are closed, and production now runs v0.9.x, so this is done.

Duplicate claims from #83 were not all cleared before the deploy. What they still cause is tracked in #188 (a delete can remove a name another record set owns), #155 (a claim of a different type at an owned name), and #201 (one writer per zone).