feat: Databricks Unity Catalog Registration

[falloficaruss]

What this PR does / why we need it:

L1 PR (#6515) added the databricks_uc offline store — it reads from Unity Catalog Delta tables for point-in-time joins, historical
features, and monitoring. That's the read path.

This L2 PR adds the write/registration path. When you run feast apply, it now registers each FeatureView as a UC feature table via Databricks'
FeatureEngineeringClient. Without it, a FeatureView defined in Feast is invisible in Unity Catalog — data scientists can't discover it in
Catalog Explorer, can't see its primary keys or metadata, and there's no governance lineage tying the Feast definition to what's in UC.

What it does:

• After registry updates during feast apply, hooks in and calls fe_client.create_table() (or ALTER TABLE for updates) for each FeatureView
• Maps FeatureView entities → UC primary keys
• Syncs tags, description, owner into UC table metadata
• Supports per-FV opt-out and catalog/schema/table overrides via FeatureView tags

Why it matters — issue #6499's core requirement: teams want one definition in Feast (entities, TTLs, PIT joins, serving API) while keeping UC
as the governance catalog. Without L2, UC is just a dumb storage layer. With L2, UC becomes the canonical catalog for discovery, access
control, and lineage — matching what Databricks Feature Store users expect.

Which issue(s) this PR fixes:

Partially Closes - #6499

Checks

• I've made sure the tests are passing.
• My commits are signed off (git commit -s)
• My PR title follows conventional commits format

Testing Strategy

• Unit tests
• Integration tests
• Manual tests
• Testing is not required for this change

Misc