Balance performance and cost with frozen tier support in data stream lifecycle (DLM)

## What the feature is
Frozen tier support in data stream lifecycle (DLM)
## Value proposition
Platform and observability teams running long data retention face a trade-off between cost and simplicity. Keeping data on the hot tier is fast but expensive, while moving it to the cheaper frozen tier has meant authoring an ILM policy and understanding the cluster's storage topology. Frozen tier support in data stream lifecycle (DLM) lets these teams move aging data to the frozen tier by setting a single retention value, with no policy authoring and no tier or hardware knowledge required. Data stays fully searchable as partially-mounted searchable snapshots, at a fraction of the storage cost.
## Expected behaviors
- Set a `frozen_after` value in a data stream lifecycle to automatically move data to the frozen tier once it reaches that age.
- Combine `frozen_after` with existing `data_retention` and `downsampling` in the same lifecycle configuration.
- Configure a cluster-level default snapshot repository once, and DLM uses it for all frozen data. It is pre-populated on Elastic Cloud Hosted, and can be pointed at a customer-owned repository.
- Configure and preview the frozen phase in Kibana, in Streams (Retention tab) and Index Management (Data Streams), on the same lifecycle timeline as hot and downsampling.
- Available on Stateful deployments with an Enterprise license. Not applicable to Serverless, where data tiering is managed by Elastic.

No source files or tests are named. Start by locating the data stream lifecycle (DLM) implementation and the Kibana Streams Retention and Index Management Data Streams entry points, then trace how lifecycle phases are configured and previewed. Done means frozen_after works with data_retention and downsampling, uses the configured snapshot repository, and respects the stated deployment and license limits.

Written by the indexing model from the issue text.