[Bug] Fetcher-level pydantic ValidationError returns 500 "Unexpected Error" instead of 422 (e.g. bls_search without category)

Describe the bug When a query-parameter validation error is raised inside a fetcher's pydantic model (rather than at the FastAPI request layer), the REST API surfaces it as HTTP 500 "Unexpected Error" instead of a 422. The same class of problem — an invalid/missing request parameter — gets a 422 when FastAPI catches it, so clients see inconsistent semantics for identical mistakes.

Concrete case: economy/survey/bls_search declares category as required in BlsSearchQueryParams, but the endpoint accepts a request without it and 500s during fetch. (Encountered via OpenBB Workspace's "Validate widgets" sweep, which probes endpoints with default/empty params — the resulting 500 blocks connecting an otherwise healthy backend.)

To Reproduce

1. OpenBB Platform 4.7.2 with openbb-bls installed (any bls_api_key state).
2. openbb-api --host 127.0.0.1 --port 6900
3. curl -i "http://127.0.0.1:6900/api/v1/economy/survey/bls_search?provider=bls&include_extras=false&include_code_map=false"

Response (HTTP 500):

{"detail": "Unexpected Error -> ValidationError -> 1 validation error for BlsSearchQueryParams\ncategory\n  Field required [type=missing, input_value={'query': ''}, input_type=dict]\n    For further information visit https://errors.pydantic.dev/2.13/v/missing"}

Expected behavior HTTP 422 with the standard FastAPI validation error shape, i.e. pydantic ValidationError raised during QueryParams construction in the provider layer should be mapped to a request-validation response, not to "Unexpected Error". (Ideally category's requiredness would also be reflected in the OpenAPI/widgets.json metadata so clients don't issue the invalid request in the first place.)

Desktop:

• OS: Debian 12 (python:3.12-slim container, linux/amd64)
• Python version: 3.12
• OpenBB Platform version: openbb 4.7.2, openbb-platform-api 1.3.6