When request_method is POST, the plugin reads the entire client request
body into memory to forward it to the authorization service, with no upper
bound. Add a max_req_body_size option (integer, default 1048576, minimum 1)
passed to core.request.get_body() so oversized bodies are rejected with 413
instead of being buffered without limit.

…e forward-auth default

Extend the max_req_body_size request-body cap to the AI proxy plugins and
align the forward-auth default:

- ai-proxy / ai-proxy-multi: add max_req_body_size (default 67108864 = 64 MiB);
  oversized requests are rejected with 413 in access() before the body is
  parsed for LLM proxying
- forward-auth: raise the max_req_body_size default from 1 MiB to 64 MiB so
  existing large-body POST auth flows are not affected by the default

Docs and e2e tests updated.

ai-proxy/ai-proxy-multi enforced max_req_body_size by calling
core.request.get_body(max) at the top of access() and discarding the result.
get_body() does not cache, and the body is read again immediately by
detect_request_type -> get_json_request_body_table, so every request buffered
the body twice. For large AI JSON bodies (which nginx spills to a temp file)
this doubled the body read and cost ~7-9% throughput in benchmarks (1/5/10 MB).

Read the body once instead:
- core.request.get_request_body_table / get_json_request_body_table take an
  optional max_size, forwarded to their single internal get_body() call.
- ai-proxy/base.lua detect_request_type forwards the limit into that parse and
  maps an oversized body to 413 (preserving the "failed to read request body"
  log); all other read/parse failures stay 400.
- ai-proxy / ai-proxy-multi drop the read-and-discard get_body() block and run
  detect_request_type first, so oversized requests are rejected before any
  balancer / DNS / health-check work.