[Spark] Only attempt server-side planning for Delta tables in loadTable

[chenwang-databricks]

Description

AbstractDeltaCatalog.loadTable called ServerSidePlannedTable.tryCreate on every table returned by super.loadTable and returned the resulting SSP table early, before the case o => o fallthrough:

val table = ... // super.loadTable(ident)
ServerSidePlannedTable.tryCreate(spark, ident, table, isUnityCatalog).foreach { sspt =>
  return sspt
}
table match {
  case v1: V1Table if DeltaTableUtils.isDeltaTable(v1.catalogTable) =>
    loadCatalogTable(ident, v1.catalogTable)
  case o => o
}

Server-side planning only applies to Delta tables, but running tryCreate ahead of the match means it also sees non-Delta tables and catalog-specific shapes that are meant to pass through unchanged. In particular, when DeltaCatalog delegates to a Unity Catalog catalog, a metric view comes back as a MetadataTable wrapping a ViewInfo; tryCreate can capture that and short-circuit view loading instead of letting it flow through case o => o to the resolver.

This moves the tryCreate attempt inside the Delta-V1Table branch so SSP is only attempted for Delta tables; everything else (non-Delta tables, view-shaped relations) flows through case o => o unchanged:

table match {
  case v1: V1Table if DeltaTableUtils.isDeltaTable(v1.catalogTable) =>
    ServerSidePlannedTable
      .tryCreate(spark, ident, table, isUnityCatalog)
      .getOrElse(loadCatalogTable(ident, v1.catalogTable))
  case o => o
}

Behavior for Delta tables is unchanged (SSP still attempted, falling back to loadCatalogTable); only non-Delta / view shapes are no longer captured by SSP.

How was this patch tested?

build/sbt spark/compile. The change is a localized, type-preserving transformation of existing loadTable logic (tryCreate returns Option[ServerSidePlannedTable]; getOrElse(loadCatalogTable(...): Table) widens to Table). No behavior change for Delta tables; the affected path is the catalog-delegation case where a non-Delta/view relation must pass through unchanged.

Does this PR introduce any user-facing changes?

No.