fix(fk): inline FK referencing a compound PK points at the table-level form

ADR-0043 D4 residual: an inline column-level FK (`<col> REFERENCES P(a,b)`)
is single-column by construction, so referencing a parent's compound PK
gave the generic arity error ("1 foreign-key column(s) on the child side,
but `P`'s key has 2..."). It now points the user at the table-level form:
"an inline column reference can only name one column ... Use the table-level
form instead: FOREIGN KEY (<columns>) REFERENCES P (a, b)".

- Adds `inline: bool` to SqlForeignKey, set by the grammar's single shared
  builder consume_fk_reference (true for the inline path, false for the
  table-level and ALTER paths).
- resolve_fk_parent_columns takes `inline` and tailors the arity-mismatch
  message when an inline FK meets a compound key.

Tests: parse-layer (inline=true / table-level=false) + end-to-end worker
refusal wording. 2209 pass / 0 fail / 1 ignored. Clippy clean.

src/dsl/command.rs

@@ -45,6 +45,13 @@ pub struct SqlForeignKey {
     pub parent_columns: Option<Vec<String>>,
     pub on_delete: ReferentialAction,
     pub on_update: ReferentialAction,
+    /// `true` for an inline column-level FK (`<col> REFERENCES …`),
+    /// `false` for the table-level `FOREIGN KEY (…)` and `ALTER …`
+    /// forms. An inline FK is single-column by construction, so when
+    /// it references a compound key the resolver points the user at
+    /// the table-level form rather than emitting the generic arity
+    /// error (ADR-0043 D4).
+    pub inline: bool,
 }
 
 /// A column at table-creation time: a name, a user-facing