[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/__tests__/dns/dns-provider-parity.test.js

@@ -183,8 +183,9 @@ describe('RFC2136 listRecords via AXFR (BIND 9 parity, DC-171)', () => {
     const [, args] = execFile.mock.calls[0];
     expect(args[0]).toBe('@192.0.2.10');
     expect(args.slice(1, 3)).toEqual(['-p', '53']);
-    expect(args[3]).toBe('AXFR');
-    expect(args[4]).toBe('other.example.com.');
+    // dig's documented positional contract: [name] [type] — zone before AXFR
+    expect(args[3]).toBe('other.example.com.');
+    expect(args[4]).toBe('AXFR');
     expect(args.slice(5)).toContain('+onesoa');
     const kIdx = args.indexOf('-k');
     expect(kIdx).toBeGreaterThan(-1);