What this PR does / why we need it:

feast_feature_server_request_total is labelled endpoint, status, and status is only ever success or error, depending on whether the handler raised. That has two problems:

• A client error (unknown feature view or feature service, a denied permission) and a server error (the online store is down) end up in the same error bucket, so you can't alert on server-side failures without also paging on bad client requests.
• Handlers that return an error response without raising are counted as success. That covers the 404 and 422 from /v1/vector_stores/{id}/search, and the 409 from async /materialize and /materialize-incremental when a materialization is already running.

This PR adds a status_class label (2xx, 4xx, 5xx) based on the HTTP status code the server actually responds with:

• When the handler raises, the status code is worked out the same way the REST exception handling answers. FeastError subclasses use their own http_status_code(), HTTPException uses its status_code, and anything else is a 500.
• RequestMetricsContext gets a status_code attribute (default 200), following the existing feature_count / feature_view_count pattern. Handlers set it when they return a non-2xx response. The vector store search and the two materialize conflict paths now do this.
• The existing status label stays, so dashboards and alerts that use it keep working. It is now derived from the status code too: success below 400, error otherwise. The only behaviour change is that the returned 404/422/409 responses above now count as error, not success.
• status_class is added only to the counter, not to the latency histogram, so histogram cardinality does not change.

Docs: the metrics table in the Python feature server reference now lists the label, there is a short "Request status labels" section with an example PromQL query, and the performance tuning guide mentions the label.

Example:

sum by (endpoint) (rate(feast_feature_server_request_total{status_class="5xx"}[5m]))
  / sum by (endpoint) (rate(feast_feature_server_request_total[5m]))

Which issue(s) this PR fixes:

Fixes #6641

Checks

• I've made sure the tests are passing.
• My commits are signed off (git commit -s)
• My PR title follows conventional commits format

Testing Strategy

• Unit tests
• Integration tests
• Manual tests
• Testing is not required for this change

New tests in sdk/python/tests/unit/test_metrics.py:

• track_request_latency maps exceptions to the right class: a plain error gives 5xx, FeatureViewNotFoundException and FeastPermissionError give 4xx, and HTTPException(404) / HTTPException(503) give 4xx / 5xx.
• A status_code set on the yielded context is used for both labels (202 gives success/2xx; 404, 409 and 503 give error).
• Through the FastAPI app: /get-online-features that fails with a not-found error answers 404 and records 4xx, and an unexpected error answers 500 and records 5xx. Async /materialize against a feature view that is already materializing answers 409 and records 4xx.

The existing assertions now include the new label. test_metrics.py passes (141 tests), and 16 of those tests fail without the source change. ruff check, ruff format --check and mypy on feast/metrics.py and feast/feature_server.py are clean.