fix(ui): stop the composer radius from clipping the first glyph

The inner textarea kept a 12px radius after its side padding was cleared, so the first character was cut into an arc. Only .composer textarea is now border-radius 0. The outer frame is unchanged.

Verified: chat-reading-load-mobile.test.ts was 7 pass / 1 fail before the CSS change, then 8 pass / 0 fail / 0 cancelled. tsc --noEmit exit 0. npm run lint 0 errors.

Co-Authored-By: Grok (agent loop)

frontend/DESIGN.md

@@ -344,6 +344,7 @@ Radii have two visual steps. Controls use 8px (`--radius-md`; `--radius-xs` and
 - **Queue:** one pending card (`.composer-queue`) sits above the field while an answer is in flight. Copy: “已排队，回答结束后发出”, plus the text and a 44px “撤回”. A second Enter appends to the same card with a newline. Successful settlement sends it; stop, failure, or recovery puts the text back in the field. The send button is disabled while a card is waiting. No spinner.
 - **Accessibility:** persistent label where practical; composer has an explicit accessible label.
 - **One composer:** the rectification surface renders the same `ChatComposer` as the main chat; there is no second composer. A surface that owns its own draft passes it as `value`; the main chat reads the draft store. Both count down from the same 500-character ceiling through `CharacterRemaining`, which the composer renders inline and only once `characterRemainingVisible()` is true — it no longer has a permanent container. Controls that belong to the composer go through the `toolbar` slot; nothing is stacked below it.
+- **Inner field corners:** the textarea inside `.composer` has `border-radius: 0`. Rounding stays on the outer `.composer` only. The field has no horizontal padding, so a radius on the textarea itself clips the first glyph's left edge (BUG-1311).
 
 ### Answer start anchor