Add Hover provider support

Add Hover provider support

Add hover as a remediation provider in records.json so both the CLI
(--provider hover) and the web app emit Hover-panel-specific fix instructions
for the 13-record Thundermail set (1 MX, 5 SRV, 4 TXT, 3 DKIM CNAME).

Internal ticket: TBPRO 6940
(6940_HOVER_DNS_MITCHENER.CA, domain example.com).

⚠️ Ship as UNVERIFIED first. The SRV field layout below is confirmed from a
screenshot of the live Hover Edit DNS Record form; the MX/TXT/CNAME field labels come
from Hover's official Managing DNS Records at Hover reference tables, not a live add-record screenshot. Follow the
godaddy/ionos precedent: prefix each header string UNVERIFIED — until confirmed
end-to-end, then drop the prefix.

🎯 example.com is the verification target. It's hosted on Hover (ns1.hover.com/
ns2.hover.com) and is currently 10/13 — three SRV records have a port typo (433
instead of 443 on _jmap/_caldavs/_carddavs). Once the hover block is in, the
checker's SRV fix strings can be eyeballed directly against the live Edit DNS Record
form the user already has open, then the port fixed to reach 13/13.

Add-record model

Hover uses a single Add-a-record form with a Type dropdown (like bunny/godaddy,
not per-type sections like cosmotown).

Path: Hover control panel → your domain → DNS section → Add a record → choose Type,
fill fields, Save. TTL defaults to 15 minutes.

Key conventions (from docs + the live SRV screenshot):

• Apex host = literal @ for MX and TXT (Hover's docs say "@ for the root domain").
• SRV splits the _service._protocol label into separate Service (_jmap) +
  Protocol (_tcp) fields — the same reason the {service}/{protocol} tokens exist
  for GoDaddy/IONOS. BUT Hover's SRV Subdomain (optional) field is left blank
  for the apex (the panel shows .example.com beside an empty box), not @. The
  existing {srvhost} token yields @, so this needs a new {srvsubhost} token =
  the SRV "rest" label but empty at the apex (mirroring how {subhost} relates to
  {host}). Add it to both interpreters (Python + JS), kept identical.
• CNAME cannot live on the root at Hover (docs), but all three DKIM CNAMEs are on
  subdomains (tm1._domainkey …), so this is a non-issue for our record set.

Field mapping

Work items

• Add {srvsubhost} token to resolve_record (Python) and resolveRecord (JS) — identical.
• Add the hover provider block to records.json (headers UNVERIFIED — prefixed).
• Update README.md provider list + a Hover paragraph.
• Update CLAUDE.md crucial-decisions with Hover's quirks.
• Verify against example.com on the live panel, then drop UNVERIFIED —.

🤖 Generated with Claude Code

Start with resolve_record in the Python interpreter and resolveRecord in the JavaScript interpreter, then inspect the provider patterns in records.json for the single-form field mappings. Update README.md and CLAUDE.md as listed, and verify the Hover output against example.com’s live panel, including the 13-record set and SRV subdomain behavior. Done means both interpreters support {srvsubhost}, the hover block is present, and the verified headers no longer need the UNVERIFIED prefix.