fix(faces): minibuffer faces inherit mode.text-entry, as ADR 004 says (improvise-nn4s.2)

Answers ChatGPT Codex's P2 on PR #319.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VdfEGXA7aJ6ftMsCc9PJze

context/test-evidence/protocol.md

@@ -1283,3 +1283,19 @@ glance, and the axis faces exist for exactly that, so two axes resolving alike
 defeats them. It now asks the shipped theme rather than an enum's arms, which
 is the stronger question: two distinct `AxisColor` arms could always have been
 mapped to one terminal colour.
+
+### a_theme_that_restyles_text_entry_reaches_every_minibuffer
+
+ADR 004 says `minibuffer.*` inherits `mode.text-entry` directly. PR #319's first
+head gave the minibuffer faces a `minibuffer` base face instead, and ChatGPT
+Codex flagged it (P2): face parents are compatibility behaviour once a theme
+can be downloaded, so a theme that restyles `mode.text-entry` must reach every
+prompt. The test overrides only `mode.text-entry` with italic, an attribute no
+minibuffer face states in the shipped theme, and asserts every
+`minibuffer.<entry>` resolves italic. A test that sets a colour instead would
+be vacuous, because each minibuffer face states its own colours.
+
+**Failed first**, against the `minibuffer` base parent: `Edit` resolved to
+`Normal`. It passes under the accepted chain. The no-op oracle
+`the_shipped_theme_reproduces_every_migrated_literal` passed both before and
+after the change, which shows the change moved no pixel.