[grade=B urn:ump:wokpmecjfauc7jvnxyyyu4fq3zkkvwge455a5mxlmi3pdzkfdw3a] fix(DC-171): AXFR dig args to documented order (zone before type) — deploy-judge blocker

Deploy gate dc-prod-deploy-dc171 (grade D, urn:ump:iesjvepuqb5poim7wu22ff4jtd5vhpw2lotfhogljemsw2h4y6vq)
blocked the cutover: listRecords built 'dig @srv -p port AXFR zone', but
dig's documented positional contract is [name] [type]. BIND 9.18 accepts
either order (live-checked), so the bug was invisible on this host's dig;
older 9.11-9.16 on other distros follow the documented order. Fixed to
'zone AXFR', test asserts the production argv, and the corrected code path
was LIVE-VERIFIED against a real DNS server: actual AXFR of zone 'sami'
via the adapter itself — 48 records parsed (SOA/A/NS), zero mocked pieces.

Parity suite: 24/24.

dashcaddy-api/src/dns/dns-providers/rfc2136.js

@@ -337,10 +337,13 @@ class RFC2136Provider extends BaseDNSProvider {
     if (!effectiveZone) throw new Error('Missing required config: zone');
     const fqdnZone = this._ensureFqdn(effectiveZone);
 
+    // dig positional contract is `dig [@server] [name] [type]` — zone name
+    // FIRST, then the AXFR request type (BIND 9.18 happens to accept either
+    // order, but 9.11-9.16 on older distros follow the documented order).
     const args = [
       `@${this.server}`,
       '-p', String(this.port),
-      'AXFR', fqdnZone,
+      fqdnZone, 'AXFR',
       '+nocomments', '+onesoa', '+nostats',
       '+time=10', '+tries=1',
     ];