[BUG] FileSizeFilter maxInMemorySize(-1) buffers entire request body in memory before size check (DoS)

- Severity: Medium
- Location:
`shenyu-web/src/main/java/org/apache/shenyu/web/filter/FileSizeFilter.java:62-64` (constructor sets `-1`), `:76` (`bodyToMono(DataBuffer.class)` reads entire body), `:78` (size check fires only after full buffering)
-
Description:
The constructor sets `maxInMemorySize(-1)` (unlimited). `serverRequest.bodyToMono(DataBuffer.class)` at line 76 reads the **entire** multipart body into a single in-memory `DataBuffer` with no size cap. The size check at line 78 only fires **after** the full body is already buffered. An attacker can send a 10 GB multipart body; the gateway buffers all 10 GB, then rejects it as "too large" — but the OOM damage is already done.
-
Impact:
Memory-exhaustion DoS. A single malicious request can crash the gateway process.
-
Suggested fix:
Set `maxInMemorySize` to a bounded value (e.g. `fileMaxSize * BYTES_PER_MB`) so the codec rejects oversized bodies during buffering, or switch to a streaming size-check.
-
Confidence: High
- Related existing: #4405 / #4505 — those are about the API and the leak; the DoS aspect of `-1` is not in either.

---
_Identified during the 2026-08-02 deep re-scan; full list in [`docs/scan2-2026-08-02/00-consolidated-critical-high.md`](docs/scan2-2026-08-02/00-consolidated-critical-high.md)._