dnsforward: add use_client_addr_from_ecs for ECS-based client identification

[elkrammer]

Closes #2514.

Adds a new option to identify clients by the EDNS Client Subnet (ECS) data injected into incoming requests by a forwarder, instead of the connection address. Without this, all queries appear to come from the forwarder's address and per-client filtering, query logs, and statistics lose client identity.

dnsmasq supports this via add-subnet=32,128 (RFC 7871); other forwarders with ECS support also benefit.

The existing edns_cs_use_custom option sends a custom IP out to upstream resolvers for CDN routing. This new option is the inverse: it reads the client address in from incoming ECS options for client identification.

What changed

Backend - new config flag use_client_addr_from_ecs (default false):

• ecsClientAddr extracts the client IP from the ECS option in incoming requests, with ecsSubnetAddr handling IPv4/IPv6 family detection
• dnsContext.clientAddr() returns the ECS address when valid, falling back to the connection address
• all consumer sites (blocked-client check, rDNS/WHOIS, per-client filtering, query log, stats) use dctx.clientAddr()
• OpenAPI spec and test data updated

Frontend - new checkbox in Settings -> DNS -> EDNS Client Subnet:

• "Use client address from ECS" toggle, disabled when EDNS client subnet is off

Testing

• go test ./internal/dnsforward/, go test ./internal/home/ pass
• go vet, gofumpt, gocyclo --over 10 clean
• End-to-end on a real LAN: dnsmasq with add-subnet=32,128 forwarding to AGH - query log shows real client IPs (eg. 192.168.0.163/32) instead of the forwarder's address