feat: Version-pinning for FeatureService (online + offline) - #6718

Closes #6717.
Related to #6389 (feature versioning in offline retrieval).

What

Lets a FeatureService pin a specific historical FeatureView / OnDemandFeatureView version, honored by both get_online_features and get_historical_features. Feast's docs currently list this as a known limitation ("Feature services always resolve to the active (promoted) version"); this closes that gap.

Commits

1. fix: Pin FeatureView version in FeatureService projections — stamp projection.version_tag from the source view's version in FeatureService.__init__; read projection.version_tag (instead of None) in utils._get_feature_views_to_use. version="latest" is unaffected.
2. feat: Support string feature references in FeatureService — features accepts "<fv>[@<version>][:<feature>]" strings, resolved once in FeatureStore.apply via FeatureService.resolve_pending_refs. Factors _parse_feature_or_view_ref out of _parse_feature_ref (optional :feature).
3. fix: Resolve version-pinned OnDemandFeatureViews in offline retrieval — shared utils._get_requested_on_demand_feature_views used by all three unversioned ODFV call sites; pinned ODFV refs now resolve to the pinned snapshot offline. This is the offline-retrieval versioning gap tracked in Proposal: Version-qualified feature refs in get_historical_features (offline store versioning) #6389.
4. docs: Document FeatureService version pinning — alpha versioning page + enable_online_feature_view_versioning docstring clarified to note it gates offline too; Known Limitations updated.

Problem

Building a service from a version-pinned FeatureView silently falls back to the promoted version:

fv  = FeatureView(name="driver_stats", version="v2", ...)
svc = FeatureService(name="model_v1", features=[fv[["conv_rate"]]])
svc.feature_view_projections[0].version_tag    # -> None   (should be 2)
svc.feature_view_projections[0].name_to_use()  # -> "driver_stats"  (should be "driver_stats@v2")

Two bugs cause this: FeatureService.__init__ never translates the view's version string into projection.version_tag, and utils._get_feature_views_to_use hard-codes the version as None for the FeatureService branch. A related pre-existing bug (#6389) breaks offline retrieval of version-pinned OnDemandFeatureViews: offline stores re-fetch ODFVs via an unversioned registry.list_on_demand_feature_views, so a pinned ODFV ref raises ValueError: Could not find feature view from reference ... or silently drops features across every offline backend.

Design notes for reviewers

• Priority ordering (commit 2): a pinned string ref always resolves from registry.get_feature_view_by_version, never from fvs_to_update (the apply batch only ever holds "latest" objects and would substitute the wrong schema). Covered by test_pinned_ref_ignores_fvs_to_update.
• Backward compatible: unversioned refs / version="latest" behave exactly as before; every existing (unversioned) FeatureService is unaffected.
• Flag name: enable_online_feature_view_versioning is misleadingly scoped to "online" — it gates both paths. Clarified in the docstring/docs here rather than renamed (rename would be a breaking config change; happy to follow up if maintainers prefer).

Tests

New unit tests: test_feature_service_versioning.py (object + string-ref pinning, proto round-trip, backward compat, error guards, priority ordering) and test_odfv_offline_versioning.py (version-aware ODFV resolution, v0 fallback, non-ODFV skip, dedup). All pass; ruff (0.16.0) + mypy clean on changed files.