Add D034: form error copper styling (pending) to decisions log

- Documented the two-layer error styling inconsistency and recommended fix
- Added form error colour normalisation as Phase 4 item in review plan

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/memory/decisions-log.md

@@ -278,6 +278,15 @@ contradict a previous one.
 **Affects:** FuneralFinder stories (title changes), component-registry (V3 = done, V1/V2 = archived), retroactive review (only V3 gets full treatment)
 **Alternatives considered:** Deleting V1/V2 — rejected because user needs them for client walkthroughs.
 
+### D034 — Form error styling should use copper, not red (pending)
+**Date:** 2026-03-29
+**Category:** token
+**Decision:** Pending — form error borders and helper text should use copper (#B0610F) instead of MUI's default red (#BC2F2F). Page-level error messages already use copper as of the grooming pass. Atom-level styling (ToggleButtonGroup error border, TextField/OutlinedInput error border, FormHelperText) still uses `palette.error.main` (red).
+**Rationale:** FA's grief-sensitive context makes aggressive red inappropriate for form validation. D024 established that labels stay neutral on error; extending this principle to borders and helper text creates a fully warm error experience. Page-level error messages already use `var(--fa-color-text-brand)` (copper) — atom-level should match.
+**Recommended approach:** Override `MuiFormHelperText`, `MuiOutlinedInput`, and ToggleButtonGroup error styles in the MUI theme to use copper. Keep `palette.error.main` red for non-form uses (destructive buttons, system alerts).
+**Affects:** src/theme/index.ts, ToggleButtonGroup atom, all form-consuming components
+**Alternatives considered:** Changing `palette.error.main` globally to copper — rejected because destructive action buttons and system alerts may genuinely need red.
+
 ### D033 — Retroactive review uses P0/P1 only, interleaved with new work
 **Date:** 2026-03-27
 **Category:** architecture