…INSERT (#331)

`detect_drift` previously ignored columns present in the source but
absent from the target. The docstring claimed "they appear naturally
via SELECT *", but the runtime's incremental INSERT path then issues
`INSERT INTO target SELECT * FROM source` against a target whose
schema is fixed — and BigQuery / Snowflake / Databricks all reject
the INSERT with `Inserted row has wrong column count`. The natural
"source schema evolves; replicate again" workflow was structurally
broken.

This PR:

- Adds `added_columns: Vec<ColumnInfo>` to `DriftResult` and populates
  it in `detect_drift` from the same single pass over source columns.
- New helper `drift::generate_add_column_sql` mirroring the existing
  `generate_alter_column_sql`. Standard `ALTER TABLE … ADD COLUMN`
  works across all four adapters today; no dialect override needed.
- Runtime change in `run.rs`: when the drift result reports added
  columns (and DropAndRecreate isn't already firing), execute the
  ALTER statements before continuing with the regular INSERT path.
  Surfaces as `action: "add_columns"` in the run output's
  `drift.actions_taken` so orchestrators can observe schema evolution
  alongside data movement.

Verified end-to-end via the existing `live/drift/run.sh`, extended
into a three-stage flow:

1. Initial replication of a 3-column source (no drift).
2. `ALTER source ADD COLUMN region`; rerun — asserts `add_columns`
   action fires and target gains the column without a full refresh
   (historical rows stay, new rows include the source value).
3. DROP + CREATE source with `id` type changed `INT64`→`STRING`;
   rerun — asserts `drop_and_recreate` action fires and target's
   id column is now STRING.

Idempotent across consecutive runs.

A sibling gap remains: the `AlterColumnTypes` action is detected in
`drift.rs` for safe widenings but the runtime at `run.rs:4105` still
only wires `DropAndRecreate`. Captured as finding #9 in
`live/README.md`; safe widenings silently fall through to the next
INSERT.