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

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