fix(batch-requests): missing the port number error when APISIX listens on a unix socket

[nic-6443]

Description

When APISIX listens on a unix domain socket (e.g. behind a sidecar or local proxy via nginx_config.http_server_configuration_snippet), calling the batch-requests endpoint fails with:

{"error_msg":"connect to apisix failed: missing the port number"}

The plugin loops the pipelined requests back to APISIX itself with httpc:connect("127.0.0.1", ngx.var.server_port), but nginx's $server_port is an empty string when the inbound request arrived over a unix socket, so the connect fails.

This PR makes the loopback connect fall back to the first TCP port found in apisix.node_listen from the local config when $server_port is empty. Since the value in the local conf is not normalized by the CLI, both config forms are handled: a plain port number, and an array of port numbers or {ip, port} tables. If no TCP port can be resolved at all, the plugin now returns a clear 503 explaining that batch-requests needs a TCP listener to loop back requests.

This follows the direction explored in the PoC #11782 (falling back to node_listen). An alternative would be to connect back over the unix socket itself, but the listening socket path is not exposed through any nginx variable, so that is left as possible future work.

Added a regression test that injects an extra listen unix: listener into the test server and sends the batch-requests call over it: it fails with the missing the port number error before the fix and passes after.

Which issue(s) this PR fixes:

Fixes #11781

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)