fix: replace strdup(error) with nginx pool allocation in config handlers

[eilandert]

In ngx_conf_set_rules, ngx_conf_set_rules_file, and ngx_conf_set_rules_remote, rule load errors returned a strdup()- allocated string. Nginx treats the returned char* as a constant string and never frees it, causing a heap leak on every failed nginx -s reload when rule files have errors.

Replace with ngx_pstrdup(cf->pool, ...) so the error string is allocated from the config pool and freed automatically when nginx reloads configuration.

[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

[tomsommer]

Confirming the problem this PR addresses: the strdup() in the three modsecurity_rules* handlers is never released, and under valgrind it shows as a per-failed-parse leak (nginx -t with a bad rule, or a bad configuration delivered by SIGHUP to a running master; a -s reload from a separate process does not accumulate because that process exits).

Two points on the replacement:

1. ngx_pstrdup() allocates src->len bytes and copies them without a terminating NUL (src/core/ngx_string.c), but ngx_conf_handler() prints the returned message with "%s" (src/core/ngx_conf_file.c), so the emerg line reads past the end of the allocation. An explicit ngx_pnalloc(cf->pool, len + 1) plus rv[len] = '\0' avoids that.
2. If ngx_pstrdup() returns NULL, the handler returns NULL, which is NGX_CONF_OK: the configuration error would be silently accepted. Returning NGX_CONF_ERROR in that case keeps nginx failing closed.

libmodsecurity's own error string is a separate leak (it is heap-allocated by libmodsecurity and must be released with msc_rules_error_cleanup(), available since 3.0.13); #398 handles that and the equivalent path in merge_conf(), and deliberately leaves the strdup lines to this PR to avoid overlapping. Found during a valgrind audit of the connector done with Claude Fable 5.1.