[nishantmonu51]

Adds time_grains to metrics views so a project can declare the grains its dashboards offer, including sub-hour and multi-hour buckets.

• A time_grains list on a metrics view replaces the default grain set in explore (chart, TDD, pivot, scheduled reports) and canvas (filter bar, widget inspector). Omitting it keeps today's behavior: the standard grains at or above smallest_time_grain.
• Ten TimeGrain multiples join the catalog: 5m, 10m, 15m, 30m, 2h, 3h, 4h, 6h, 8h, 12h. Each divides its parent unit, so buckets stay aligned to local midnight in the query timezone. The canonical token (10m) is accepted by resolver queries, metrics SQL (date_trunc('10m', ts)), explore URLs (grain=10m), canvas time_filters and additional_time_grain.
• Every dialect buckets multiples on the local wall clock: DuckDB time_bucket, ClickHouse toStartOfInterval, Druid time_floor, Snowflake TIME_SLICE, StarRocks time_slice, Pinot DATETIMECONVERT, and floor-within-parent expressions for Databricks and BigQuery. Spine bins, legacy time-series null filling, comparison offsets and rollup derivability handle them.
• Adaptive grain selection only picks declared grains; bookmarks, URL state and explore presets round-trip the new values.
• Multiples are aggregation grains only: smallest_time_grain, rollup time_grain and requires/per/window.order selectors reject them at parse time. The list is a UI contract and is not enforced on API queries, same as smallest_time_grain today.
• Docs: time_grains reference entry and a "Custom time grains" section in the time series guide.

type: metrics_view
timeseries: ts
smallest_time_grain: minute
time_grains: [10m, 30m, hour, day, week]

Not included: a multi-select for time_grains in the visual metrics editor. For frontend reviewers: protobuf-es stops stripping the TIME_GRAIN_ prefix once a value such as TIME_GRAIN_5_MINUTE exists, so the TS proto enum is now referenced as TimeGrain.TIME_GRAIN_DAY.

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!