UX/Filtering Bug: Clients with "Use global settings" disabled cannot be tested in Check Filtration or targeted via Custom Rules

[masterwishx]

Description of the Problem

In the latest versions of AdGuard Home, the client configuration logic was updated. When editing a specific client (e.g., Kevin_PC-Lan), if you disable the "Use global settings" toggle to isolate the client, it completely removes the client's ability to interact with the main "Custom Filtering Rules" page.

This creates two critical issues:

1. Check Filtration tool becomes useless for this client:
   If I try to test a domain using the "Check Filtration" (Проверить фильтрацию) utility and enter this specific ClientID/IP, the tool completely ignores any blocking rules and falsely outputs: "Not found in your filters list". It seems the backend engine immediately drops the query simulation before evaluating custom syntax because of the global settings flag.

2. No way to apply individual custom domains:
   Since the text input box for individual client rules was removed from the Client UI in recent updates, and the client now completely bypasses the global "Custom Filtering Rules" list, there is no way to block a specific custom domain (e.g., a private domain like upgrader.pro) exclusively for this client using standard syntax like ||domain.com^$client='Client_Name'.

Expected Behavior

• The "Check Filtration" tool should accurately simulate and display hits on rules matching the $client modifier, even if that client has "Use global settings" turned off.
• There should be a clear, documented path to apply individual custom domain block/allow rules to an isolated client without forcing them to inherit the entire global blocklist environment.

Actual Behavior

The custom rules with $client='Client_Name' or $client=IP are completely ignored by the engine and the testing tool if "Use global settings" is turned off for that client.

# Kevin PC Blocked
||pornhub.com^$client='Kevin_PC-Lan'
||upgrader.pro^$client='Kevin_PC-Lan'