Remove init_sql and migrate setup patterns to query composition

Problem

The init_sql and init_sql_file source-config fields injected arbitrary bootstrap SQL at connection time, which broke in read-only execution environments (e.g. DuckDB over HTTP, hosted adapters) and created a hidden side-effect channel outside the normal compile → execute pipeline. Dashboards that relied on init SQL for table creation or CSV loading could not run in restricted contexts, and the implicit execution made it difficult to reason about what SQL actually ran during a dashboard render. This was a blocking issue for the FT Analytics pilot, where read-only enforcement is required.

Context

• init_sql and init_sql_file are deprecated and removed from source config and SQL adapter execution paths.
• Existing examples and docs that relied on bootstrap SQL are migrated to query-composition setup (for example _csv_setup.yml imports).
• Read-only runtime behavior is simpler: no source bootstrap SQL path remains to bypass or police.
• Automated coverage protects migration behavior and prevents init_sql regressions from reappearing.

Possible Solutions

Plan

• Remove init_sql/init_sql_file fields from source schema and validation.
• Remove adapter execution logic that resolves/runs init SQL during connection creation.
• Add migration guidance and examples for shared setup query files (for example _csv_setup.yml) imported into top-level dashboard queries:.
• Update affected examples to use {% raw %}{{ queries.* }}{% endraw %} composition and/or CSV query sources rather than bootstrap SQL.
• Add tests that assert init_sql is rejected/unsupported and that replacement query-composition workflows behave correctly.
• Validate behavior in FT Analytics pilot environment and document known limits.
• Update issue and changelog notes with rollout and verification evidence.

Implementation Progress

• GitHub issue: https://github.com/fivetran/dataface/issues/279

Review Feedback

• [ ] Review cleared