feat: colour output tags by status, not mode — readable error bodies (#10)

The output tag was tinted by submission mode for every line kind, so a
[system] line and an [error] line rendered with an identical leftmost
tag — distinguishable only by body colour. And flooding the whole error
body in red made long messages hard to read.

Colour the tag by message status instead (its OutputKind): [system] →
green, [error] → red; the echo tag keeps the mode tint (ADR-0037's
actual purpose — per-command success rides the ✓/✗ marker). Bodies go
neutral; the error body stays bold for weight (rustc-style: severity-
coloured label, readable bold message). Yields a status traffic-light
matching the ✓/✗ palette.

Narrows ADR-0037's mode side-channel to the echo line it was always for.
ADR-0037 Amendment 1; closes the tag-colour gap ADR-0040 flagged as OOS.

docs/adr/0037-execution-time-mode-side-channel.md

@@ -203,8 +203,74 @@ Two refinements found when building, recorded so the ADR matches reality:
   `EffectiveMode`) is Tier-1 testable, and the worker-side threading
   becomes live + end-to-end testable the moment the echo reads it.
 
+## Amendment 1 — Output tag is colour-coded by status, not mode (2026-05-31, issue #10)
+
+The original side-channel (§ above) exists "purely to label the
+**input-echo line**" — the `[simple]`/`[advanced]` tag whose colour
+tells the learner which mode their command ran under. In
+implementation, however, the tag-colour rule in `render_output_line`
+(`src/ui.rs`) was applied to **every** output kind, keyed on
+`mode_at_submission` regardless of whether the line was an echo. That
+over-applied the channel: a `[system]` line and an `[error]` line —
+neither of which is an input echo — both picked up the same mode tint
+(blue in simple, orange in advanced). The only thing distinguishing a
+routine `[system]` message from an `[error]` was the **body** colour
+(green vs red), while the tag — the leftmost glyph the eye lands on —
+was identical (issue #10).
+
+That is backwards for the line a learner most needs to spot fastest.
+The mode has limited value on an error line; "this is an error" has
+high value. And flooding the whole error **body** in red makes a long
+message *harder* to read, not easier.
+
+**Change — the status-coloured-tag model.** The output tag is
+colour-coded by the message's **status** (its `OutputKind`), and the
+**body** is neutral so the message text stays readable:
+
+| Kind | Tag colour | Body |
+| --- | --- | --- |
+| `Echo` | **mode tint** (`mode_simple`/`mode_advanced`) — *the sole exception* | `theme.fg` / lexed (unchanged); per-command success rides the trailing ✓/✗ (ADR-0040) |
+| `System` | `theme.system` (green) | `theme.fg` (was green) |
+| `TeachingEcho` | `theme.system` (green — it is a `[system]`-tagged line) | dim prefix + lexed SQL (unchanged) |
+| `Error` | `theme.error` (red) | `theme.fg` **+ BOLD** (was red) |
+
+This **narrows** the side-channel to its stated purpose rather than
+contradicting it: the mode tint now lives **only** on the echo tag,
+where ADR-0037 always said it belonged. Everything else reads as a
+status traffic-light — **green tag = ok/info, red tag = error** —
+which is the same palette as the ✓/✗ echo markers (ADR-0040), so the
+whole output surface speaks one colour vocabulary.
+
+**Why bold-neutral for the error body** (not plain, not red). This is
+the established diagnostic-rendering convention — `rustc`, `clang`,
+`tsc`, and most linters colour the **severity label** and render the
+**message** in the default foreground (bold), not a wall of severity
+colour. The red moves to the tag (the scan target); the body keeps
+weight via BOLD without the readability cost of coloured prose.
+
+**Scope / non-changes.**
+
+- `OutputLine.mode_at_submission` is **unchanged** — still carries the
+  mode for the echo tag. Only *which kinds consult it for colour* changed.
+- The ✓/✗ completion markers (ADR-0040) are untouched — they already
+  use `theme.system`/`theme.error` directly, and now visually rhyme
+  with the new tag colours.
+- This supersedes the three options sketched in issue #10 (red tag /
+  amber attention tag / glyph) with a cleaner fourth model that also
+  fixes body readability and the `[system]` tag in one rule. ADR-0040
+  had flagged the `[error]`/`[system]` tag colours as orthogonal and
+  out of its scope (issue #10) — this amendment closes that gap.
+
+**Coverage** (`src/ui.rs` tests): `system_line_renders_green_tag_and_neutral_body`,
+`error_line_renders_red_tag_and_bold_neutral_body`,
+`echo_tag_keeps_the_mode_tint_not_a_status_colour` (locks the sole
+exception across both modes), `teaching_echo_tag_is_green_like_other_system_lines`.
+
 ## See also
 
+- ADR-0040 — the ✓/✗ completion markers whose green/red palette the
+  status tag now matches; it deferred these tag colours as orthogonal
+  (issue #10), closed by Amendment 1.
 - ADR-0033 Amendment 3 — deferred this side-channel; defines the
   intrinsic command-identity model this ADR must not disturb.
 - ADR-0030 §10 — the DSL → SQL teaching bridge (the motivating consumer).