Handle a renamed main domain on cPanel

[0kaba0]

Closes #87.

Changing an account's main domain in WHM removed the old zone from the panel and created a new one — and SecondDNS heard about neither. The old zone stayed on the secondary for a domain that no longer exists; the new one was never registered. Same defect as DirectAdmin #78, filed as #87 and deliberately left until there was a cPanel server to watch it on.

What WHM actually sends

Whostmgr::Accounts::Modify, probed on both stages during a real rename:

pre    domain=my999domain.com  user=my123domain  newuser=my123domain
post   domain=my999domain.com  user=my123domain  newuser=my123domain

Only the new name, on both stages. The old one is nowhere in the payload — which is exactly why cPanel's own Cpanel::Hooks::ChangeDomains captures it at stage pre before the change lands.

The hook does the same: at pre the account on disk is still the old one, so the old main domain comes from userdata and the new one from the payload.

WHM fires this event for every account change — quota, package, contact address — so the hook queues nothing unless the two names actually differ.

Live

11:02:25  Zone renamed: my999domain.com -> my777domain.com (cpanel hook)
11:02:35  delivered delete my999domain.com
11:02:40  delivered create my777domain.com

and the secondary answers SOA ... 2026090604 for the new name, nothing for the old one.

Tests

tests/test_cpanel_rename.sh, 12 checks: both operations and their order (delete old, then create new), an unchanged domain queueing nothing, a quota-only change with no domain in it, an unknown account, an IDN new name arriving as punycode, and an unusable new name that still removes the old zone and logs the refusal.

Mutations: dropping the old-vs-new comparison fails 1 — the hook would fire on every quota change; skipping the removal of the old zone fails 5.

This closes the cPanel round

Five defects found on the live box today, each of which made the integration non-functional: the PowerDNS reload (#89), the payload read from the wrong level, Accounts::Remove carrying no domain, a subscription to an event cPanel does not have (all #90), and this one.

[0kaba0]

Ready to merge. Verified: the hook runs at stage pre and assembles the pair the way cPanel's own ChangeDomains does — old name from userdata, new from the payload; an unchanged domain and a domain-less change (quota, package) queue nothing, with the mutation on that condition red; delete then create in queue order; IDN in punycode; an unusable new name still removes the old (consistent with the DirectAdmin hook and with the master, which no longer has it). Registered in install and removed in uninstall, CI green, no attribution trailers, comments within two lines apart from the file header. Closes #87.

[0kaba0]

Docs updated in this PR too — the cPanel README was describing an integration that never worked.

It said "two shell scripts ... 4 events", and two of those four (Api2::AddonDomain::addaddon, deladdondomain) are events current cPanel does not fire. Now three scripts and five events, each with what it actually does:

• Accounts::Create
• Accounts::Remove (pre) — every zone of the account, read from userdata because the event carries only the username
• Domain::park — addon, alias and parked domains all arrive here
• Domain::unpark
• Accounts::Modify (pre) — the rename, old name from userdata

The Api2 pair is documented as what it is: a fallback for older cPanel.

Beta banner removed, and the panel table in the root README now reads 5 events, incl. rename + addon/alias against cPanel/WHM 136 — the version the round was actually run on, rather than the v82+ floor.

Added a note that WHM refuses Unicode in the domain field, so an IDN must be entered in punycode there. DirectAdmin accepts either, so this is worth saying on the cPanel page specifically.

Checked both ways: every event the installer registers appears in the README, and every event the README names is registered.

[0kaba0]

Verified the docs half both ways on the head: the seven events the installer registers (Accounts::Create/Modify/Remove, Domain::park/unpark, and the two Api2 AddonDomain fallbacks) are all named in the cPanel README and nothing named there is unregistered; no 'beta' left on the cPanel page or in the root table; version stated as the one the circle ran on; the punycode note is cPanel-specific and says so. CI green, no attribution trailers. Ready to merge — with it all four panels are documented as what they are.