fix: header registration visibility and body-loop edge case

[fzipi]

Summary

• msc_add_n_request_header() and msc_add_n_response_header() signal failure via their return value, but every call site discarded it — the resolver dispatch loop in ngx_http_modsecurity_header_filter(), the raw headers_out/headers_in list loops, and the nested Keep-Alive add inside ngx_http_modsecurity_resolv_header_connection(). A failure (OOM inside libmodsecurity) meant that header simply never reached the WAF with no visibility into it. These now log a warning on failure. Unlike the request/response body phase (handled in a separate PR), dropping a single header isn't equivalent to skipping inspection outright, so this logs rather than fails the request closed.
• ngx_str_to_char() returns NULL for a zero-length ngx_str_t (not an error, just "empty"), and most callers already check for it (e.g. n_uri, host_name), but client_addr and server_addr in the connection-info block didn't. An empty addr_text (e.g. some unix-socket configurations) would pass NULL straight into msc_process_connection(), which expects a C string.
• The response-body loop in ngx_http_modsecurity_body_filter() never broke out after running msc_process_response_body() on the buffer carrying last_buf. A filter upstream of us (sub_filter, gzip, ...) can append a trailing buffer after the last_buf link in the same chain, which would loop back around and call msc_append_response_body() again on an already-finalized transaction. The full chain is still forwarded to the next filter regardless of where this loop stops inspecting, so nothing is dropped from the response.

Test plan

• Build against libmodsecurity v3 and run the existing tests/*.t suite (prove modsecurity*.t) to confirm no regression.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud