[SPARK-56920][SQL][FOLLOWUP] Format METRIC_VIEW DESCRIBE output distinctly from VIEW

[cloud-fan]

What changes were proposed in this pull request?

CatalogTable.toJsonLinkedHashMap emits the view-binding fields (View Schema Mode, View Catalog and Namespace, SQL Path, View Query Output Columns, View Original Text) for any isViewLike table. After SPARK-56920 added METRIC_VIEW to isViewLike, those fields are now also emitted for metric views. None of them apply: a metric view's viewText is a YAML body (not a SQL query bound to a schema with schema-evolution mode), so those rows are at best inert and at worst misleading.

Narrow the view-binding block to tableType == CatalogTableType.VIEW, and give METRIC_VIEW its own branch that emits just View Text plus a Language: YAML tag so consumers can dispatch on the view_text format.

Why are the changes needed?

To make DESCRIBE TABLE EXTENDED AS JSON output for METRIC_VIEW accurately reflect its YAML nature, and avoid emitting SQL-view-specific binding fields that have no meaning for a metric view.

This also makes the call site fork-friendly: forks that extend isViewLike to include additional view-like kinds (materialized views, streaming tables, etc.) no longer accidentally inherit the SQL-view binding block for those kinds.

Does this PR introduce any user-facing change?

Yes. DESCRIBE TABLE EXTENDED AS JSON on a METRIC_VIEW:

• No longer emits View Original Text, View Schema Mode, View Catalog and Namespace, SQL Path, or View Query Output Columns.
• Now emits Language: YAML.
• Still emits View Text (the YAML body).

How was this patch tested?

Compiles cleanly. Existing MetricViewV2CatalogSuite covers the v2-catalog path via DescribeV2ViewExec, not this v1 toJsonLinkedHashMap path, so it is unaffected.

Was this patch authored or co-authored using generative AI tooling?

No.

[cloud-fan]

@chenwang-databricks @dtenedor

[cloud-fan]

thanks for the review, merging to master/4.x/4.2!