What this PR does / why we need it:

Summary

Introduces LabelView, a new alpha-stage Feast primitive that manages mutable labels and annotations separately from immutable feature data stored in regular FeatureViews. This supports multi-labeler workflows (human reviewers, automated safety scanners, reward models) where different sources independently write labels for the same entity keys.

LabelView is fully opt-in — existing workflows are unaffected unless a user explicitly defines one.

What's included

Core implementation (feast.labeling module)

• LabelView class inheriting from BaseFeatureView, with label-specific attributes: labeler_field, conflict_policy, retain_history, reference_feature_view
• ConflictPolicy enum (LAST_WRITE_WINS, LABELER_PRIORITY, MAJORITY_VOTE)
• Protobuf definition (LabelView.proto) with LabelViewSpec, LabelViewMeta, and ConflictResolutionPolicy

Full SDK integration

• FeatureStore.apply() — registers LabelViews, auto-registers their PushSource, validates name uniqueness across all view types
• FeatureStore.push() — routes push data to LabelView when its PushSource matches
• FeatureStore.get_historical_features() — works via batch_source/stream_source properties on LabelView
• FeatureStore.teardown() — includes LabelView tables
• FeatureStore.list_label_views() / get_label_view() — new public API methods
• FeatureService composability — LabelViews can be included alongside regular feature views

Registry support (all backends)

• File registry — full CRUD, apply_materialization, name-conflict checks
• SQL registry — label_views table, _infer_fv_table/_infer_fv_classes support, proto() builder
• Remote (gRPC) registry — label_view arm added to ApplyFeatureViewRequest oneof, full client + server wiring
• Snowflake registry — DDL for LABEL_VIEWS table, correct column-name mapping in delete_feature_view

CLI

• feast label-views list — lists all label views with name, entities, conflict policy
• feast label-views describe <name> — shows full label view details
• feast feature-views list unchanged (label views are only in their dedicated command)

Permissions

• LABEL_VIEW = 11 added to Permission.proto Type enum
• _PERMISSION_TYPES map updated for from_proto/to_proto roundtrip

Regression safety

• LabelViews are excluded from feast materialize / materialize-incremental (labels come in via push(), not batch materialization); explicit error if attempted by name
• No changes to existing feature-views list output
• All registry proto() builders include label_views so cached/exported blobs are complete
• Cross-type name uniqueness enforced via _ensure_feature_view_name_is_unique

Documentation

• Docstrings with [Alpha] tags and Google-style Args blocks on all public classes/methods
• Sphinx/RST API reference entries for LabelView and ConflictPolicy
• Concept guide (docs/getting-started/concepts/label-view.md) with usage examples, conflict policies, and alpha limitations
• Alpha limitations clearly documented: conflict_policy stored but not enforced at read time (requires online-store query-path changes); retain_history stored but not enforced at write time (requires online-store write-path changes); batch materialization not supported

Tests

• 30 unit tests covering creation, defaults, proto roundtrip, copy/equality, validation, FeatureService composition, registry proto roundtrip, batch_source/stream_source properties, name-conflict detection, and MaterializationTask acceptance

Alpha Limitations

• conflict_policy — persisted in registry metadata but not enforced during get_online_features. Online store returns last-written row regardless of policy.
• retain_history — persisted but not acted on. Online store always overwrites previous value.
• Batch materialization — not supported; labels ingested via FeatureStore.push() only.

Test Plan

• All 30 test_label_view.py unit tests pass
• All 5 test_registry_diff.py tests pass (including test_diff_registry_objects_permissions)
• No linter errors introduced
• Existing feature view / entity / feature service workflows unaffected when no LabelView is defined
• Manual: feast apply with a repo containing a LabelView definition
• Manual: feast label-views list / feast label-views describe
• Manual: FeatureStore.push() to a LabelView's PushSource

Which issue(s) this PR fixes:

#5456