Minor fixes; add highlighted lines

Author: themisvaltinos

docs/guides/configuration.md

@@ -869,7 +869,7 @@ See [here](https://sqlglot.com/sqlglot/dialects/dialect.html#NormalizationStrate
 
 You can also define gateway specific `model_defaults` in the `gateways` section, which override the global defaults for that gateway.
 
-```yaml linenums="1"
+```yaml linenums="1" hl_lines="6 14"
 gateways:
   redshift:
     connection:
@@ -891,9 +891,9 @@ This allows you to tailor the behavior of models for each gateway without affect
 
 For example, in some SQL engines identifiers like table and column names are case-sensitive, but they are case-insensitive in other engines. By default, a project that uses both types of engines would need to ensure the models for each engine aligned with the engine's normalization behavior, which makes project maintenance and debugging more challenging.
 
-Gateway-specific `model_defaults` allow you to change how SQLMesh performs identifier normalization *by engine* to align the different engines' behavior. 
+Gateway-specific `model_defaults` allow you to change how SQLMesh performs identifier normalization *by engine* to align the different engines' behavior.
 
-In the example above, the project's default dialect is `snowflake` (line 14). The `redshift` gateway configuration overrides that global default dialect with `"snowflake,normalization_strategy=case_insensitive"` (line 6). 
+In the example above, the project's default dialect is `snowflake` (line 14). The `redshift` gateway configuration overrides that global default dialect with `"snowflake,normalization_strategy=case_insensitive"` (line 6).
 
 That value tells SQLMesh that the `redshift` gateway's models will be written in the Snowflake SQL dialect (so need to be transpiled from Snowflake to Redshift), but that the resulting Redshift SQL should treat identifiers as case-insensitive to match Snowflake's behavior.
 

docs/guides/multi_engine.md

@@ -97,8 +97,6 @@ In this setup, the PostgreSQL engine is set as the default, so it will be used t
     )
     ```
 
-Given this configuration, when a model’s gateway is set to duckdb, it will be materialized within the PostgreSQL `main_db` catalog, but it will be evaluated using DuckDB’s engine.
-
 Given this configuration, when a model’s gateway is set to DuckDB, the DuckDB engine will perform the calculations before materializing the physical table in the PostgreSQL `main_db` catalog.
 
 ```sql linenums="1"
@@ -139,7 +137,7 @@ First, add the connections to your configuration and set the `gateway_managed_vi
 
 === "YAML"
 
-```yaml linenums="1"
+```yaml linenums="1" hl_lines="30"
 gateways:
   redshift:
     connection:
@@ -178,7 +176,7 @@ variables:
 
 === "Python"
 
-```python linenums="1"
+```python linenums="1" hl_lines="48"
 from sqlmesh.core.config import (
     Config,
     ModelDefaultsConfig,
@@ -255,7 +253,7 @@ FROM
 
 For the `athena_schema.order_status` model, we explicitly specify the `athena` gateway:
 
-```sql linenums="1"
+```sql linenums="1" hl_lines="4"
 MODEL (
   name athena_schema.order_status,
   table_format iceberg,
@@ -271,7 +269,7 @@ FROM
 
 Finally, specifying the `snowflake` gateway for the `customer_orders` model ensures it is isolated from the rest and reads from a table within the Snowflake database:
 
-```sql linenums="1"
+```sql linenums="1" hl_lines="4"
 MODEL (
   name snowflake_schema.customer_orders,
   table_format iceberg,
@@ -303,7 +301,7 @@ Models:
 Models needing backfill:
 ├── awsdatacatalog.athena_schema.order_status: [full refresh]
 ├── redshift_schema.order_dates: [full refresh]
-└── silver.snowflake_schema.customers: [full refresh]
+└── silver.snowflake_schema.customer_orders: [full refresh]
 Apply - Backfill Tables [y/n]: y
 ```