fix(max): constrain ai chat prompt height

[lordspline]

Problem

Long prompts in the PostHog AI chat could keep growing the prompt textarea until the send button was pushed out of reach.

Closes PostHog#62461

Changes

• Add textareaClassName to LemonTextArea so callers can style only the actual <textarea> instead of also styling the wrapper.
• Cap the Max chat textarea height to min(40vh, 16rem) and enable internal vertical scrolling so the send button remains visible.
• Cover the Max chat input with a regression test asserting the scroll constraint is applied.

How did you test this code?

I am an agent. I ran:

FLOX_DISABLE_METRICS=true flox activate -- bash -c 'export PATH="$PWD/.flox/cache/venv/bin:$PATH"; hogli test frontend/src/scenes/max/components/QuestionInput.test.tsx'\nFLOX_DISABLE_METRICS=true flox activate -- bash -c 'pnpm exec oxfmt frontend/src/lib/lemon-ui/LemonTextArea/LemonTextArea.tsx frontend/src/scenes/max/components/QuestionInput.tsx frontend/src/scenes/max/components/QuestionInput.test.tsx'\n```\n\nI also ran `pnpm --filter=@posthog/frontend typescript:check`, but it is currently blocked in this checkout by missing generated Kea type files and existing unrelated TypeScript errors outside this change.\n\n👉 _Stay up-to-date with [PostHog coding conventions](https://posthog.com/docs/contribute/coding-conventions) for a smoother review._\n\n## Automatic notifications\n\n- [ ] Publish to changelog?\n- [ ] Alert Sales and Marketing teams?\n\n## Docs update\n\nNo docs update needed.\n\n## 🤖 Agent context\n\n**Autonomy:** Human-driven (agent-assisted)\n\nCaptain Capy implemented this from the public GitHub issue. The fix keeps the existing Max chat layout and LemonTextArea behavior intact while adding a targeted escape hatch for textarea-only styling, because the existing `className` is intentionally applied to both the wrapper and the textarea.

[capy-ai]

🔍 Visual QA — fix(max): constrain chat input height

Tested on live dev stack (master vs PR branch applied locally via HMR). Surface: Max AI chat (/project/{id}/ai).

---

Desktop — 1280 × 900

Before (master)	After (PR)
maxRows={10} constrains textarea to ~216 px; native browser scrollbar appears when content overflows	CSS max-h-[min(40vh,16rem)] + overflow-y: auto added explicitly; scrollbar styled via show-scrollbar-on-hover (hidden until hover)

Before:

After:

---

Narrow — 390 × 700

Before	After
Textarea height=216 px (maxRows), scrollHeight=1192 px; native scrollbar visible	Same visual height, CSS constraint max-h-256px at this viewport; scrollbar styled

Before:

After:

---

Key findings

• ✅ Send button (→) remains visible and accessible in all tested states
• ✅ Auto / Add context toolbar row remains accessible below the input
• ✅ textareaClassName correctly targets only the inner <textarea> element (not the wrapper <div>)
• ℹ️ At desktop (1280 px), the visual change is subtle — maxRows={10} already caps at ~216 px, and min(40vh, 16rem) = 256 px is a looser bound. The CSS constraint becomes the binding limit when viewport height falls below ~540 px (i.e. on short screens or with soft keyboard open), where 40vh < 216 px.
• ℹ️ show-scrollbar-on-hover replaces the always-visible native browser scrollbar with a PostHog-styled thin scrollbar that appears on hover — consistent with how other scrollable areas in the app behave (Navigation, ScrollableShadows, ModeSelector).

One minor note: In LemonTextArea, the existing className prop is applied to both the outer wrapper <div> (line 79) and the <TextareaAutosize> (line 83). The new textareaClassName goes only to <TextareaAutosize>. This is the right separation, though it also means any class in the current className that's textarea-specific could be migrated over in a follow-up for clarity.

Overall the behavior is correct and the send button stays accessible. 👍