Add GoDaddy provider support

[rtanglao]

Add GoDaddy provider support

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

Internal ticket: TBPRO 6850 (6850_GODADDY_CUSTOM_DOMAIN).

⚠️ Ship as UNVERIFIED first. Field conventions below are derived from GoDaddy's
official help docs + a screenshot of the live SRV add-record form — but not yet
confirmed against a live end-to-end add on a real GoDaddy-hosted domain. Follow the
spaceship precedent: prefix the header strings UNVERIFIED — until validated, then
drop the prefix (see the "Pending verification" pattern in recent commits).

Add-record model

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

Path: Domain Portfolio → select domain → DNS tab → DNS Records → Add New Record →
choose Type, fill fields, optional Add More Records, then Save / Save All Records.

Key conventions:

• Apex host = literal @ (GoDaddy explicitly uses @ for the root — do NOT leave
  it empty, unlike bunny/cosmotown). So use the {host} token, not {subhost}.
• MX and SRV have separate Priority (and Weight/Port for SRV) fields — never fold the
  priority into Value.
• TTL defaults to "1 Hour"; leave it unset.
• On Save, domains with Domain Protection / 2-step verification may prompt for a
  one-time code (informational only).
• Domain must be on GoDaddy nameservers for these panels to apply.

Field mappings (for the records.json provider block)

Token vocabulary available today: {host}, {subhost}, {target}, {value},
{match}, {priority}, {weight}, {port}.

MX — Type=MX, Name={host}, Priority={priority}, Value={target} (mail host only), TTL default
[add-an-mx-record-19234]

TXT (covers SPF / MTA-STS / TLSRPT / DMARC — GoDaddy adds SPF as a plain TXT) —
Type=TXT, Name={host}, Value={value}, TTL default
[add-a-txt-record-19232,
add-an-spf-record-19218]

CNAME (3 DKIM) — Type=CNAME, Name={host} (DKIM selectors are prefixes, so the
"Name cannot be @" rule doesn't bite), Value={target}, TTL default
[add-a-cname-record-19236]

SRV — ⚠️ fully decomposed into 7 inputs (transcribed from the live form screenshot,
stored at 6850_GODADDY_CUSTOM_DOMAIN/6850-godaddy-adding-srv-record.png):

Form field	Value
Type	SRV
Service	e.g. _jmap — the service label
Protocol	e.g. _tcp
Name	@ (apex) → {host}
Value	{target} (host.domain.com)
Priority	{priority}
Weight	{weight}
Port	{port}
TTL	default

[add-an-srv-record-19216]

⚠️ Implementation gap — new interpreter tokens needed for SRV

GoDaddy is the first provider that splits the SRV _service._protocol label into two
separate inputs. Every other provider puts the whole _jmap._tcp string in the Host
field, so there are no {service} / {protocol} tokens today.

This means GoDaddy support is not a pure records.json addition — it also needs the
tiny interpreter in both front-ends (resolve_record in Python, resolveRecord in JS)
extended to derive {service} and {protocol} by splitting the SRV host label on the
first . (_jmap._tcp → service _jmap, protocol _tcp), with the SRV Name becoming
the apex @. Per CLAUDE.md these two interpreters are duplicated and must stay in sync.

Acceptance criteria

• godaddy block added to records.json (MX/SRV/TXT/CNAME) using the mappings above.
• {service} / {protocol} tokens implemented identically in the Python and JS interpreters.
• uv run verify_thundermail_dns.py example.com --provider godaddy renders all 13 records
  (both --fix-format table and long) without error.
• Web app "GoDaddy" provider mirrors the CLI output (table + detailed).
• README provider list updated (the one hardcoded spot).
• Headers prefixed UNVERIFIED — until confirmed against a live GoDaddy add-record panel;
  then verified end-to-end (add records on a GoDaddy-hosted test domain, confirm 13/13 via
  --resolver <domain's GoDaddy authoritative NS>) and prefixes dropped.

Reference docs (GoDaddy Help CA)

• MX — https://www.godaddy.com/en-ca/help/add-an-mx-record-19234
• TXT — https://www.godaddy.com/en-ca/help/add-a-txt-record-19232
• SPF — https://www.godaddy.com/en-ca/help/add-an-spf-record-19218
• CNAME — https://www.godaddy.com/en-ca/help/add-a-cname-record-19236
• SRV — https://www.godaddy.com/en-ca/help/add-an-srv-record-19216

Local source PDFs + SRV form screenshot: THUNDERBIRD_2023/TBPRO/6850_GODADDY_CUSTOM_DOMAIN/.

[rtanglao]

Implemented in e0b3b5e (on main) — shipping UNVERIFIED as planned.

What landed:

• godaddy provider block in records.json (MX/SRV/TXT/CNAME). Single Add-record form with a Type dropdown; apex Name = @ ({host}); MX has a separate Priority; SRV fully decomposed into Type/Service/Protocol/Name/Value/Priority/Weight/Port.
• New {service} / {protocol} / {srvhost} tokens added to the shared interpreter in both verify_thundermail_dns.py (resolve_record) and app.js (resolveRecord), derived by splitting the SRV host label on . — GoDaddy is the first panel that breaks _service._protocol into separate inputs. Kept in sync per CLAUDE.md.
• Headers carry an UNVERIFIED — prefix.
• Docs: README provider list + note; RELEASE_NOTES pending-verification checklist, table row, and godaddy notes section.

Verified:

• No regression — existing 6 providers' output (table + long) and invalid-domain exit-2 are byte-identical to pre-change baselines.
• CLI renders all 13 records in both --fix-format table and long; SRV splits correctly.
• Web app mirrors the CLI (drove it headless): godaddy in dropdown, live DoH lookups ran (1 passed / 12 failed, same as CLI), SRV split into Service/Protocol/Name, all 13 rendered, no CSP violations or console errors.

Still open (why this issue stays open): the final acceptance criterion — live end-to-end confirmation. To promote: add one record of each type on a live GoDaddy-hosted domain, confirm 13/13 via --resolver <the domain's GoDaddy authoritative NS>, then drop the UNVERIFIED prefixes in records.json and the notes in README.md + RELEASE_NOTES.md. Also unconfirmed: exact MX/TXT/CNAME field labels (only the SRV add-form was screenshotted) and whether any target Value needs a trailing dot.