ALTER TABLE ADD COLUMN bypasses the generated-columns feature flag and produces an unopenable database

[LeMikaelF]

Description

ALTER TABLE ... ADD COLUMN ... AS (...) adds a generated column even when the --experimental-generated-columns feature is disabled, while CREATE TABLE with the same column is rejected. The resulting schema is persisted but can no longer be parsed, so reopening the database fails and the table becomes inaccessible.

Reproducer

-- Session 1
CREATE TABLE t(a);
ALTER TABLE t ADD COLUMN b AS (a);
-- Turso: succeeds
-- SQLite: succeeds (VIRTUAL generated columns are allowed via ADD COLUMN)

-- Session 2 (reopen the same database file)
SELECT * FROM t;
-- Turso: Error: Parse error: table 't' uses generated columns but the generated_columns feature is not enabled
-- SQLite: returns the row(s); the database opens normally

The gate is inconsistent across paths. CREATE TABLE with a generated column is correctly rejected with the same feature disabled:

CREATE TABLE g(a, b AS (a));
-- Turso: Parse error: Generated columns require --experimental-generated-columns flag

Per SQLite ALTER TABLE documentation: "The column may not be GENERATED ALWAYS ... STORED, though VIRTUAL columns are allowed." SQLite supports adding VIRTUAL generated columns and reopens the database without error.

core/translate/alter.rs:1084-1109 - the AddColumn branch validates the generated expression but never checks connection.experimental_generated_columns_enabled(), unlike CREATE TABLE (core/translate/schema.rs:743). The load-time gate at core/schema.rs:1780 then rejects the persisted schema, making the database unopenable.

---

This issue brought to you by Mikaël and Claude Code.