[BUG] FileSizeFilter leaks pooled DataBuffer on oversized-file rejection path

- Severity: High
- Location:
`shenyu-web/src/main/java/org/apache/shenyu/web/filter/FileSizeFilter.java:76-84` (rejection path, no release) vs `:98` (`.doFinally` release only on success path)
-
Description:
When the size check at line 78 rejects the upload (`dataBuffer.capacity() > Constants.BYTES_PER_MB * fileMaxSize`), the lambda returns `WebFluxResultUtils.result(exchange, error)` at line 84 **without releasing `dataBuffer`**. The `doFinally(signalType -> DataBufferUtils.release(dataBuffer))` is only on the success-path `bodyInsert.insert(...).then(...).doFinally(...)` chain (line 98), not the rejection branch.
-
Impact:
Every rejected oversized multipart upload leaks one pooled `DataBuffer` (up to `fileMaxSize` MB of Netty direct memory). An attacker sending oversized multipart bodies can exhaust the pooled direct-memory arena, causing `OutOfDirectMemoryError` with no GC recovery.
-
Suggested fix:
Add `.doFinally(signalType -> DataBufferUtils.release(dataBuffer))` to the rejection-path Mono, or restructure so both paths share a single outer `doFinally`.
-
Confidence: High
- Related existing: #4505 (CLOSED, the original leak fix) — that fix only patched the success path and left the rejection path leaking. This is an incomplete-fix regression, not a dup.

---
_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)._

Start in shenyu-web/src/main/java/org/apache/shenyu/web/filter/FileSizeFilter.java, reading lines 76-98 and tracing both the oversized-file rejection branch and the success path. Confirm that rejected buffers are released as well as successful ones, then run the relevant web-module checks to verify the leak fix without changing the rejection response.

Written by the indexing model from the issue text.