feat: Add HTTP status class (2xx/4xx/5xx) segmentation to Feature Server error metrics

Follow-up from #5920 (Improve Feature Server Observability).

**Problem**

`request_count` in `sdk/python/feast/metrics.py` is currently labeled `endpoint, status` where `status` is only ever `"success"` or `"error"` (set in `track_request_latency`'s `try`/`except` block). This collapses all 4xx client errors and 5xx server errors into a single `"error"` bucket, which the original issue calls out as insufficient — it explicitly asks for breakdown "by HTTP status class, optionally basic error categories."

**Proposed solution**

- Extend the `status` label (or add a new `status_class` label) to capture the actual HTTP status class returned by the FastAPI handler: `2xx`, `4xx`, `5xx`.
- This requires plumbing the actual response status code into `track_request_latency` in `sdk/python/feast/metrics.py` — currently it infers success/failure purely from whether an exception was raised, not from the response's status code. Handlers in `sdk/python/feast/feature_server.py` will need to pass the resolved status code (or the FastAPI `Request`/`Response` object) into the context.
- Consider whether this is best implemented as FastAPI middleware (per the original issue's implementation note) rather than per-handler, to guarantee every request's actual status code is captured consistently rather than relying on each handler behaving correctly.
- Keep `success`/`error` as either an additional coarser label or a derived/aliased view for backward compatibility with existing dashboards, and call out any breaking change clearly in the PR.

cc: @jyejare @ntkathole