destination-snowflake: follow-ups from safe type-aware retype casts

Follow-ups from the review of https://github.com/airbytehq/airbyte/pull/83697, which replaced the unconditional retype `CAST` in `SnowflakeDirectLoadSqlGenerator.alterTable()` with per-type-pair conversion expressions. None of these are reachable bugs today; they were kept out of that PR so its proven commit stayed unchanged.

### 1. Live integration coverage for scalar -> `OBJECT` retypes

`SnowflakeTableSchemaEvolutionTest` and `SnowflakeInsertAcceptanceTest.testAppendSchemaEvolution()` run against live Snowflake but only exercise `INTEGER -> VARCHAR` and string-to-unknown retypes. Nothing covers a scalar -> `OBJECT` retype, which is exactly the failure fixed in that PR — a green connector-test job would not have caught it, and won't catch a regression. Add an integration case covering `FLOAT -> OBJECT` (nulled + `_airbyte_meta` entry) and `VARCHAR -> OBJECT` (JSON text parsed).

### 2. `normalizeType()` does not handle parameterized type literals

`buildCastExpression()` normalizes bare type names only, so `VARCHAR(16777216)`, `NUMBER(38,0)`, or `TIMESTAMP_TZ(9)` would miss the typed branches and fall through to the plain `CAST`. This cannot happen today because precision is stripped upstream in `SnowflakeAirbyteClient.getColumnsFromDb()`, but the helper does not stand on its own if that changes. Strip the parenthesized argument list before matching.

### 3. `OBJECT_INSERT` on a NULL `_AIRBYTE_META`

The typecast-error bookkeeping `UPDATE` uses `OBJECT_INSERT("_AIRBYTE_META", ...)`, and `OBJECT_INSERT(NULL, ...)` evaluates to `NULL`, so the bookkeeping would silently no-op if that column were ever NULL. The existing `COALESCE` guards the nested `changes` array, not the outer object. The column is declared non-nullable, so this is defensive only — wrap the outer object in `COALESCE(..., OBJECT_CONSTRUCT())`.

Original oncall issue: https://github.com/airbytehq/oncall/issues/13234

---
**Internal Tracking:** https://github.com/airbytehq/oncall/issues/13234