docs: update semantic snowflake semantic views doc following CUB-2368 (cube-js#10810)

* upd

* upd

Author: MikeNitsenko

docs-mintlify/docs/integrations/snowflake-semantic-views.mdx

@@ -48,6 +48,16 @@ Alternatively, you can push Cube views into Snowflake as native semantic views.
 
 This enables you to use Cube-authored views directly in Snowflake, maintaining consistency across both platforms.
 
+### Cubes defined with `sql`
+
+When a cube uses the `sql` property with a plain SQL string, Cube creates a helper
+Snowflake view named `CUBE_SV_SRC_<CUBENAME>` in a configurable schema (defaults to
+`PUBLIC`) and uses that view as the source for the semantic view. For example:
+`sql: "SELECT id, status FROM raw.orders"`.
+
+Note that if you're simply referencing a table, use `sql_table` instead, as it's the
+recommended approach for straightforward table access (e.g., `sql_table: MY_SCHEMA.MY_TABLE`).
+
 ### Prerequisites
 
 The push integration uses the SQL Runner to execute DDL statements in Snowflake. To
@@ -60,6 +70,8 @@ successfully create semantic views, ensure the following:
 - The Snowflake role configured for your Cube data source (via [`CUBEJS_DB_SNOWFLAKE_ROLE`](/reference/configuration/environment-variables#cubejs_db_snowflake_role))
   has privileges to create semantic views in the target database and schema
   (`CREATE SEMANTIC VIEW` on the schema, plus `USAGE` on the parent database and schema).
+  If any cube uses a plain SQL string in its `sql` property, the role also needs
+  `CREATE VIEW` privileges on the schema where helper views are created (which defaults to `PUBLIC`).
 - The role has `USAGE` on the warehouse specified by [`CUBEJS_DB_SNOWFLAKE_WAREHOUSE`](/reference/configuration/environment-variables#cubejs_db_snowflake_warehouse)
   and `SELECT` on the underlying tables referenced by the view.
 - [`CUBEJS_DB_SNOWFLAKE_QUOTED_IDENTIFIERS_IGNORE_CASE`](/reference/configuration/environment-variables#cubejs_db_snowflake_quoted_identifiers_ignore_case)
@@ -81,9 +93,10 @@ Cube only.
 
 When pushing a Cube view to Snowflake, the following are currently not supported:
 
-- **Cubes without a `sql_table`.** Each cube referenced by the view must be
-  backed by a physical table. Cubes defined with an arbitrary `sql` block
-  (subqueries, CTEs, or other inline SQL) can't be pushed.
+- **Cubes with templated `sql`.** If a cube's `sql` property uses template
+  expressions (e.g., Jinja or dbt `{{ source(...) }}` syntax), it can't be
+  pushed. See [Cubes defined with `sql`](#cubes-defined-with-sql) for details on
+  what SQL patterns are supported.
 - **Cubes without a single-column primary key.** Every cube needs a
   `primary_key` dimension that resolves to a single physical column. Composite
   primary keys and primary keys defined as SQL expressions aren't supported.