[feature]Support Whitelist Enforcement Mode in Gateway

[immune53]

Is your feature request related to a problem? Please describe.
Currently, Reqable’s Gateway feature provides an “Allow Only” option, but the existing behavior only ignores non-allowed requests rather than actively blocking them.
In real-world testing scenarios—especially during API debugging, security testing, or traffic isolation—it is often necessary to eliminate interference from unrelated background requests (such as SDK telemetry, system services, or parallel API calls).

Because ignored requests are still transmitted, they may continue consuming bandwidth, affecting timing analysis, polluting logs, or triggering unintended backend interactions. This makes it difficult to perform accurate single-request testing or reproduce controlled traffic conditions.

Tools like Charles Proxy provide an Allow List mode, which actively drops all non-whitelisted requests, ensuring that only explicitly permitted traffic is sent. This capability is particularly important when dealing with applications generating large volumes of requests.

⸻

Describe the solution you’d like
Add a Whitelist Enforcement Mode (Strict Allow List Mode) to the Gateway feature.

In this mode:
• Only requests matching configured allow rules are permitted.
• All non-whitelisted requests are actively blocked/dropped, rather than ignored.
• Blocked requests should not be forwarded to upstream servers.
• Optionally display blocked requests in logs with a clear status (e.g., Dropped by Allow List).

This would enable:
• Precise single-request testing
• Traffic isolation during debugging
• Cleaner capture environments
• Reduced configuration complexity compared to blacklist rules

⸻

Describe alternatives you’ve considered
• Using the existing blacklist mode:
This becomes difficult and error-prone when applications generate many dynamic or unknown requests, requiring extensive rule maintenance.
• Manually disabling background services or SDK traffic:
Often impractical or impossible, especially on mobile or closed-source applications.
• Switching to Charles Proxy for strict filtering:
While effective, it breaks workflow consistency for users who prefer Reqable’s ecosystem.

⸻

Additional context
A strict whitelist behavior similar to Charles Proxy Allow Lists would significantly improve Reqable’s usability for debugging, performance testing, and security analysis scenarios.

Suggested UX improvement:
• Toggle option:
✅ Allow Only (Ignore) — current behavior
✅ Allow Only (Drop Others) — new strict whitelist mode

This enhancement would greatly simplify testing workflows when handling high-volume or noisy network traffic.