test: broaden fallback-vs-libidn2 backend parity coverage — PSLR-gnmvyymh

[bart-turczynski]

Closes the backend-parity work item (PSLR-gnmvyymh): prove the in-tree fallback and the optional libidn2 label backend make identical accept/reject decisions and produce identical canonical output across PSL-shaped domains, official RFC 3492 vectors, URLs, and edge/reject cases — and that the suite stays green with libidn2 absent.

What changed

tests/testthat/test-backends.R rewritten around a decision/output-split parity model:

• Parity is asserted on the decision (accept vs reject) and on accepted output — never on raw error text. The two backends word rejections differently (e.g. xn--zzz999.com: fallback "Truncated punycode input" vs libidn2 "string contains invalid punycode data"), so message equality would produce false failures. The old test compared raw output strings and only ever fed valid inputs, so it never hit this.
• Broader corpus: multi-script U-labels, PSL-shaped multi-label names, A-label idempotence, non-transitional sharp-s, single root dot, and a reject set spanning the validation pipeline (empty name/label, STD3 _, hyphen placement, whitespace, malformed ACE, >63-octet label).
• Unconditional fallback teeth (reject + round-trip) that run on every platform. With libidn2 present the public API routes label work through libidn2, so without these the fallback backend would be exercised on Linux/macOS CI only via parity equality and skipped entirely on Windows.

Verification

• Full testthat suite green locally with libidn2 present (libidn2+fallback); pre-push verify gate passed.
• CI installs libidn2 on Linux + macOS (4/5 jobs run real cross-backend parity); Windows uses fallback-only and exercises the unconditional fallback assertions, confirming "passes with libidn2 absent".

🤖 Generated with Claude Code