feat: DSL→SQL teaching echo — channel + create-table slice (ADR-0037 + ADR-0038)

Walking skeleton validating the whole echo architecture end to end; the
Command→SQL renderer currently covers `create table`, with the rest of
Bucket A / B / category-3 to follow (ADR-0038 §8).

- Channel (ADR-0037): the three-way EffectiveMode (reusing the existing
  enum, not a new SubmissionMode — recorded in the ADR) rides on
  Action::ExecuteDsl to the runtime. `replay` bypasses the interactive
  spawn, so it never echoes (silent, for free).
- Echo (ADR-0038): built at the runtime's ExecuteDsl dispatch — the worker
  gets decomposed calls, not the Command, so ADR §4's "worker builds it"
  was corrected to the dispatch layer. Gated by echo_for (advanced
  effective mode + DSL-form). Carried on DslSucceeded; rendered by
  note_ok_summary as `Executing SQL: …` immediately beneath `[ok]`. New
  src/echo.rs renderer; echo.executing_sql i18n key.
- command_to_sql: `create table` → `CREATE TABLE T (id serial PRIMARY KEY)`
  (single inline / compound table-level PK), playground type vocabulary,
  round-trip-verified against the advanced walker (the §1 contract).

Tests: echo.rs (render, round-trip contract, mode gate, Sql*-not-echoed);
app.rs (submit carries the 3-way mode; echo renders beneath [ok]).
Suite 1970/0/1; clippy clean.

docs/adr/0038-dsl-to-sql-teaching-echo.md

@@ -97,13 +97,17 @@ echoes would bury the replay summary — ADR-0037 §3).
 
 ### 4. Where it is built and rendered
 
-The **worker builds** the echo (ADR-0037 §3) — it alone holds the facts
-several echoes need: auto-resolved index / relationship names, generated
-`shortid` values, and lossy-conversion counts. It returns the echo
-payload on the result event. The **App renders** it as one or more
-**de-emphasised** `OutputLine`s beneath the `[ok]` summary, using the
-ADR-0028 styled-runs mechanism (a dimmed `Executing SQL:` prefix; the SQL
-itself in a code-ish run). One statement per line (§6 category 2).
+The echo is built at the **runtime's `ExecuteDsl` handler** (build
+correction, ADR-0037 §3 + Implementation notes): the db.rs worker
+receives *decomposed* calls, not the `Command`, so it cannot render
+`Command → SQL`. The runtime is the one place where the `Command`, the
+threaded `EffectiveMode`, and the worker's **result** (resolved auto-
+names, generated `shortid`s, conversion counts) all converge — so it
+builds the echo there, still **execution-time aware** (it consumes the
+results). The **App renders** it as one or more **de-emphasised**
+`OutputLine`s beneath the `[ok]` summary, using the ADR-0028 styled-runs
+mechanism (a dimmed `Executing SQL:` prefix; the SQL in a code-ish run).
+One statement per line (§6 category 2).
 
 ### 5. `Value → SQL-literal` rendering