Two related cases where ErrorHandlerInterceptor's global toast fired even though the calling component already recovers gracefully on its own: - GET /kyc/risk-rules 404ing (e.g. not yet deployed on a given backend) popped a raw "Http failure response ... 404" toast on the Create Client page, even though client-general-step already falls back to an empty rule set and a default risk category when this call fails. - The Clients list page fires several per-row background calls (client data/KYC/address, for every visible row) plus the main search — each already had its own catchError/error handling, but the interceptor's 500 branch had no silencing path at all (only 403/404 did, and only for a fixed set of known-optional URLs), so any backend hiccup there spammed "Internal Server Error" toasts on top of an otherwise-working page. Added a SILENT_HTTP_ERROR HttpContextToken so a caller can opt a specific request out of the toast for every status code (not just 403/404) when it already handles failure itself — threaded as an optional `silent` param through ClientsService's searchByText/getClientData/getClientKyc/ getClientAddressData (default false, so no other of their ~50+ call sites change behavior) and set from ClientsComponent's list-page calls. The risk-rules endpoint was simpler: just added to the interceptor's existing URL-based silent-request list alongside client images/KYC/pending-edits.