test+docs: lock drop-PK-refused on advanced surface; document no-PK advanced mode (#19)

Dropping a PK column was already refused in both modes via the shared
do_drop_column guard; this adds end-to-end coverage on the advanced
ALTER surface (single-column + compound PK, asserting refusal for the
right reason) and documents the asymmetry that advanced-mode SQL can
create a PK-less table (SQLite's implicit rowid keys it) while simple
mode forbids it. See issue #19 comment for the full assessment.

docs/simple-mode-limitations.md

@@ -41,6 +41,22 @@ entry names the ADR that drew the boundary.
 
 ## Table creation (ADR-0029)
 
+- **A simple-mode table always has a primary key; an advanced-mode
+  table need not.** `create table … with pk …` is mandatory in simple
+  mode (ADR-0029) — the bare `with pk` even defaults to `id serial`.
+  Advanced-mode SQL follows standard SQL and permits a *PK-less* table:
+  `create table t (a int)` declares no primary key. This is **not** a
+  storage problem — every ordinary table (STRICT included) carries
+  SQLite's implicit `rowid`, which keys it internally; only a
+  `WITHOUT ROWID` table (which this app never creates) would lack one.
+  So the simple-mode requirement is a *pedagogical* boundary (teach that
+  tables should have a key), not an engine constraint. Consequences in a
+  PK-less table, all handled: `show data … limit` falls back to rowid
+  order (no stable user-facing key to order by); `update` / `delete`
+  still target the affected rows by rowid; and there is no "PK column"
+  to drop — dropping a *declared* PK column is refused in **both** modes
+  (the shared `do_drop_column` guard: *"cannot drop primary-key column
+  …"*).
 - **`create table` declares only primary-key columns.**
   `create table T with pk …` makes every listed column part
   of the primary key; there is no simple-mode syntax for a