[BUG] CrossFilter short-circuits OPTIONS preflight with 200 OK even for disallowed origins, bypassing the filter chain

- Severity: Medium
- Location:
`shenyu-web/src/main/java/org/apache/shenyu/web/filter/CrossFilter.java:116-119`
-
Description:
The OPTIONS short-circuit `if (request.getMethod() == HttpMethod.OPTIONS) { response.setStatusCode(HttpStatus.OK); return Mono.empty(); }` is inside the `if (CorsUtils.isCorsRequest(request))` block but **outside** the `if (allowCors)` block (which ends at line 115). So when the origin is **not** allowed (`allowCors == false`), no CORS headers are set, but OPTIONS still gets `200 OK` + `Mono.empty()` — the filter chain is never called.
-
Impact:
OPTIONS preflight requests from disallowed origins bypass the entire filter chain (auth, logging, rate-limiting). The `200 OK` is misleading. Security filters positioned after CrossFilter (`@Order(-100)`) are bypassed for all CORS OPTIONS requests.
-
Suggested fix:
Move the OPTIONS short-circuit inside the `if (allowCors)` block; for disallowed origins, pass through to `chain.filter(exchange)` or return 403.
-
Confidence: High
- Related existing: SEC-16 covers `allowedOrigins("*")` in admin's `WebConfiguration`, not this OPTIONS bypass logic.

---
_Identified during the 2026-08-02 deep re-scan; full list in [`docs/scan2-2026-08-02/06-medium-tiers.md`](docs/scan2-2026-08-02/06-medium-tiers.md)._

Start in shenyu-web/src/main/java/org/apache/shenyu/web/filter/CrossFilter.java at lines 116-119 and trace how disallowed CORS OPTIONS requests are handled relative to the filter chain. Verify that allowed preflight requests retain their current success behavior, while disallowed origins either reach chain.filter(exchange) or return 403 without bypassing downstream security filters.

Written by the indexing model from the issue text.