Add features bundle resource - #6952

Changes

Adds features as a bundle resource type, so a Feature Engineering feature can be declared in databricks.yml and deployed, updated and destroyed like any other resource.

UpdateFeature accepts description and nothing else, so the adapter sends a static update_mask=description; every other field is excluded at plan level, with full_name, source and function marked recreate_on_changes from the spec's IMMUTABLE annotations. Literal catalog and schema names in full_name are rewritten into ${resources.…} references so a feature deploys after the catalog and schema it lives in.

Why

Features are currently created through the Python client or the API. Onboarding Features to direct engine is part of the proper DAB support effort for the Feature Engineering API.

Tests

• go test ./bundle/... ./libs/... ./internal/... ./cmd/... ./experimental/ssh/... . — passed
• go test ./acceptance — passed
• task generate-check — no drift
• task checks, task fmt — passed

Acceptance tests added:

• bundle/resources/features/basic — full lifecycle, request trace
• bundle/resources/features/lifecycle — cloud-capable, provisions its own table
• bundle/resources/features/remote-delete — out-of-band delete drift
• bundle/deployment/bind/feature — bind and unbind
• bundle/invariant/configs/feature.yml.tmpl — invariant coverage
• libs/testserver/feature.go — fake create/get/update/delete
• cmd/experimental/workspace_open_test.go — features URL and resource-type lists

Integration test is skipped: The cloud test environments are production workspaces, and the feature-engineering service there has not yet received a build compatible with the create payload this resource sends, so features/lifecycle fails on create for reasons unrelated to this change. Running that same acceptance test against a staging workspace already serving a compatible build passes both DMS variants with no diff against the golden, including the two bundle plan assertions that confirm no field reads back as drift.