IIS: IPv6 link-local client addresses break IP matching ("IPmatch: bad IPv6 specification")

Description

On Windows, when a client connects to the ModSecurity IIS module from an
IPv6 link-local address (fe80::/10), rule processing fails with:

ModSecurity: IPmatch: bad IPv6 specification "fe80::186d:7ec:8f88:4a0a%6".
ModSecurity: Rule processing failed (id=905110, msg=).

Any rule that matches against REMOTE_ADDR / client IP (e.g. id=905110) is
affected for such clients.

Root cause

In iis/mymodule.cpp, GetIpAddr() converts the client sockaddr to a string
with GetNameInfo(..., NI_NUMERICHOST). On Windows, GetNameInfo appends the
IPv6 zone/scope identifier ("%") to link-local addresses,
because sin6_scope_id is the interface index for fe80::/10 addresses
(Microsoft docs: "fe80::208:74ff:feda:625c%5").

ModSecurity's IP-match parser only accepts plain RFC 4291 addresses and
rejects the "%6" zone suffix, so the rule aborts.

Impact

False rule-processing failures (and effectively bypassed IP-based rules)
for any client arriving over a link-local IPv6 address on Windows/IIS.

Fix

Strip the "%" suffix from the textual IP passed to ModSecurity in
GetIpAddr(). The binary address (sin6_addr) used for the socket is
unchanged, and the zone id is irrelevant for IP matching.

See PR: https://github.com/owasp-modsecurity/ModSecurity/pull/3631

Start in iis/mymodule.cpp at GetIpAddr() and inspect how GetNameInfo formats IPv6 link-local client addresses. Verify the behavior with a Windows/IIS link-local address and confirm that IP matching completes without the zone suffix causing a parser error; PR #3631 is already linked for comparison.