Fix 402 error on authenticated API requests using search query parameter

Expected Behavior Authenticated API requests that include the search query parameter should return a 200 OK with matching results. If no matches are found, the API should return 200 OK with an empty result set and appropriate metadata (e.g., total=0), not an error status. Current Behavior Even when authenticated and able to use other endpoints successfully, any request that includes the search query parameter returns a 402 Payment Required response. An admin suggested using sort=trend and indicated that search returns an error when no results are found. This behavior prevents text search via the API and is inconsistent with standard API semantics. Possible Solution Update the search handler so that "no results" does not map to 402. Return 200 with an empty array and total=0 when there are no matches. Reserve 402 (or 403) for genuine payment/entitlement issues and include a clear, actionable error message. Return 400 for malformed search parameters and 401 for authentication failures. Align behavior across all SDKs/clients and update documentation to reflect expected status codes and response shapes for search. Add regression tests covering successful search, no-results search, and true payment-required scenarios. Steps to Reproduce Authenticate using a valid API key or Bearer token. Call a search-enabled endpoint, e.g., GET /v1/resources?search=example. Observe that the response status is 402, despite valid authentication and entitlement; the same endpoint without the search parameter returns 200. Repeat with a search term that should have matches; the request still returns 402. Context (Environment) This issue blocks implementing text search in our integration. Other API operations work as expected under the same authentication. The suggested workaround (e.g., sort=trend) does not fulfill the requirement for text-based searching, and the current 402-on-no-results behavior breaks typical search flows.