Client IP resolution differs from the reference for forwarded chains, the unix token and spoof reporting #85

I compared the client IP the engine resolves with the reference (guard_core/_utils/ip_extraction.py and _ip_in_list in _utils/access_control.py), using 104 rows of extraction expectations and 78 list-matching rows generated by running the reference functions directly. The expectations cover IPv4-mapped, bracketed and zoned addresses, ports, X-Forwarded-For chains with trusted proxies and depth, headers from untrusted peers, the unix token and invalid entries.

26 extraction rows differ. The causes:

• X-Forwarded-For entries keep their port (1.2.3.4:8080, [2001:db8::1]:443), empty entries are dropped (the reference keeps them, which changes which entry the depth selects), and a chain from a trusted proxy is not walked right to left when the declared depth over-counts the proxy hops.
• A zoned entry (fe80::1%eth0) and a mapped zoned entry are not parsed or rendered like the reference.
• A mapped peer inside an IPv4 CIDR in trusted_proxies is trusted, the reference does not trust it. A malformed CIDR reached before a match is skipped, the reference treats the list as untrusted.
• The unix token is rejected by trusted_proxies validation, so a request with no peer address cannot resolve through the forwarded chain.
• An untrusted peer sending X-Forwarded-For is not reported (no suspicious_request / spoofing_detected event, no spoof log), and none of the reference once-only chain warnings are logged.

I will align these with the reference, add the generated expectation tables as a test runner, and add engine-level tests that an IPv4 blacklist entry blocks a client that connects as ::ffff:<ipv4> (this already worked here, the test pins it).