Avoid target schema propagation into INSERT SELECT

[osipovartem]

Which issue does this PR close?

N/A. This fixes a planner regression found by the Rustice Snowflake compatibility suite.

Rationale for this change

INSERT INTO target SELECT expression FROM VALUES ... currently propagates the target table schema into the nested VALUES relation. The raw values are coerced before the SELECT expression runs. For example, inserting make_array(column1) into a list column turns the inner scalar value into a list first and produces List<List<T>>; Rustice hits the same bug when PARSE_JSON(column1) targets a native Variant field.

What changes are included in this PR?

Only provide PlannerContext.table_schema when the INSERT source itself is a direct VALUES body. INSERT ... SELECT now infers its source plan independently and continues to use the existing final projection for target-column casts and defaults.

Are these changes tested?

Yes. A planner regression covers INSERT INTO list_table SELECT make_array(column1) FROM VALUES ....

• cargo +1.94.0 test -p datafusion-sql --test sql_integration: 579 passed
• cargo +stable clippy -p datafusion-sql --all-targets --all-features -- -D warnings: passed
• cargo +1.94.0 fmt --all -- --check: passed

The repository-wide all-features clippy command is currently blocked outside this change by existing datafusion-execution tests importing unstable std::assert_matches.

Are there any user-facing changes?

INSERT ... SELECT expressions over nested VALUES are planned against their actual source types instead of the target table types. Direct INSERT ... VALUES, including placeholder type inference, is unchanged.