[BUG] MemorySafeLinkedBlockingQueue.maxFreeMemory and rejector lack volatile/visibility

- Severity: Medium
- Location:
`shenyu-common/src/main/java/org/apache/shenyu/common/concurrent/MemorySafeLinkedBlockingQueue.java:33,35,57,75`
-
Description:
`maxFreeMemory` (int) and `rejector` (ref) are non-final, non-volatile, mutated by public setters with no synchronization. `hasRemainedMemory()` and the overridden `put`/`offer` read both from arbitrary threads with no memory barrier. A runtime reconfiguration (raising `maxFreeMemory` from a config-refresh thread) is not guaranteed visible to offering threads → stale threshold, incorrect reject/accept. Swapping `rejector` concurrently can publish a partially-constructed reference.
-
Impact:
Stale threshold → tasks silently discarded/accepted contrary to operator intent after live reconfig; torn `rejector` read possible.
-
Suggested fix:
Mark both fields `volatile` (or `AtomicReference`/`AtomicInteger`); require set-before-publish if immutability preferred.
-
Confidence: High
- Related existing: none

---
_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 by reading shenyu-common/src/main/java/org/apache/shenyu/common/concurrent/MemorySafeLinkedBlockingQueue.java at lines 33, 35, 57, and 75, then trace the setters, hasRemainedMemory(), put(), and offer(). Verify the behavior under runtime updates from concurrent threads; done means updated maxFreeMemory and rejector values are reliably observed without unsafe publication.

Written by the indexing model from the issue text.