feat(infoblox): create PTR records for AAAA records

[MaxRink]

Follow-up to #69, which added AAAA records but deliberately restricted CreatePTR to A records. That restriction turned out to be more conservative than necessary — most of the reverse-zone machinery is already family-agnostic:

• rfc2317.CidrToInAddr already derives ip6.arpa nibble names for IPv6 CIDRs (verified: 2001:db8::/64 → 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa, 2001::/16 → 1.0.0.2.ip6.arpa), so Records() needed no change to fetch PTRs from an IPv6 reverse zone.
• findReverseZone uses net.ParseCIDR + net.IPNet.Contains, both already IPv6-correct.

So no new nibble helper was written — it would have been dead code.

What actually changed

• ChangesByZone derives the companion PTR change for AAAA endpoints as well as A; AdjustEndpoints/Records() track infoblox-ptr-record-exists for AAAA too.
• recordSet() addresses a PTR through ipv6addr rather than ipv4addr when the target is IPv6, both when building the object and when looking up the existing one. record:ptr carries its target in exactly one of the two fields (RecordPTR has both Ipv4Addr and Ipv6Addr; NewEmptyRecordPTR's returnFields lists both).
• ToPTRResponseMap() falls back to Ipv6Addr when Ipv4Addr is empty, so PTRs read back from an ip6.arpa zone yield a target instead of an empty string.

CreatePTR still gates all of this — no behaviour change for users who haven't opted in. As before, the reverse zone must be in DOMAIN_FILTER; the README now documents the IPv6 CIDR form.

Testing

Nibble-name derivation (table test: compressed, expanded, ULA and host forms), ip6.arpa reverse-zone matching, RecordPTR field-and-query-param assertions, and AAAA+PTR create/update/delete through ApplyChanges — including a case asserting no PTR is created when CreatePTR is disabled.

go build, go vet, go test -count=1 ./..., gofmt -l and golangci-lint run ./... (0 issues) all pass.

The tests were mutation-checked. Worth calling out one result: an early version of the ApplyChanges tests passed with the wrong WAPI field being written, because the mock reads whichever field is set. Since a wrong field means broken reverse records against a real Grid, TestInfobloxRecordSetPTR was added to assert the concrete RecordPTR fields (ipv4addr empty, ipv6addr set) and the lookup query parameter. Forcing all PTRs to write Ipv4Addr now fails TestInfobloxRecordSetPTR/ipv6 and /ipv6_expanded.

Found but deliberately left alone

findReverseZone has a pre-existing longest-prefix-match bug that affects IPv4 too: it keys networks[mask] on the second return of rZoneNet.Mask.Size() (total bits — always 32 or 128) rather than the prefix length. With both 10.0.0.0/8 and 10.0.0.0/24 present, 10.0.0.5 resolves to whichever zone comes last rather than the more specific one. Out of scope here to keep the diff focused; happy to send a separate PR if useful.

Depends on #69.