feat: Add feature_service label to Feature Server RED metrics

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

**Problem**

`sdk/python/feast/metrics.py` currently breaks out online-feature metrics by `feature_view` (see `online_features_status_total`'s `feature_view` label in `track_feature_statuses`), but there is no equivalent `feature_service` label anywhere in the metrics, even though requests to `/get-online-features` are frequently made via a named Feature Service.

**Proposed solution**

- Add a `feature_service` label to the relevant RED metrics (at minimum `request_latency`/`request_count` in the `track_request_latency` context, and consider `online_features_status_total`).
- Resolve the feature service name in the `/get-online-features` handler in `sdk/python/feast/feature_server.py` (available from the parsed request body) and pass it through via `RequestMetricsContext`, following the existing pattern used for `feature_count`/`feature_view_count`.
- Add cardinality safeguards per the original issue: make this label **opt-in** (config flag, default off) and/or support an allowlist of feature service names, since unbounded feature-service cardinality could blow up metric storage in large deployments.
- Wire the new config flag into `MetricsConfig` / `_MetricsFlags` alongside the existing per-category toggles.

cc: @jyejare @ntkathole

Start in sdk/python/feast/metrics.py with track_request_latency, track_feature_statuses, MetricsConfig, and _MetricsFlags, then trace the /get-online-features handler in sdk/python/feast/feature_server.py. Confirm how the parsed request body exposes the Feature Service and how feature_count/feature_view_count flow through RequestMetricsContext. Done means the relevant RED metrics can report feature_service safely, with the new configuration or allowlist behavior wired into the existing metric toggles.

Written by the indexing model from the issue text.