fix(Textarea): correct per-size font sizes (#738)

[barista-for-frappe]

Closes #738.

What this changes

• src/components/Textarea/Textarea.vue:120-123 — bump per-size font classes so sm=14px, md=16px, lg=18px, xl=20px. Previously sm and md both rendered at 14px and lg at 16px.

Mapping uses the project's font-size tokens from tailwind/tokens.js:

• text-base = 14px (sm)
• text-lg = 16px (md)
• text-xl = 18px (lg)
• text-2xl = 20px (xl)

Why it's safe

• Single-file, presentation-only change. No props, types, or emits touched.
• No tests assert on the size classes (Textarea.cy.ts only checks data-size attribute, not the resolved class).
• Didn't run the test suite — please run pnpm test / Cypress before merging.

What I didn't do

• The issue only specified sm/md/lg. I also bumped xl to text-2xl (20px) to preserve the progression — otherwise lg and xl would both have rendered at 18px. Revert that line if you'd rather leave xl alone.
• Didn't touch TextInput.vue, which has the same sm/md duplicate at text-base. Out of scope for this issue.

Docs preview: https://ui.frappe.io/pr-preview/pr-739/

Coverage: 49.19% (±0.00% vs main)

[barista-for-frappe]

Looks good — small presentation-only fix that matches the spec in #738.

• src/components/Textarea/Textarea.vue:120-123 — new mapping (sm=text-base/14px, md=text-lg/16px, lg=text-xl/18px, xl=text-2xl/20px) matches tailwind/tokens.js:28-31.
• No public API surface change (no props/emits/slots touched).
• The xl=text-2xl choice is reasonable to preserve the monotonic progression; you already flagged it for the reviewer.

Minor follow-up — TextInput.vue:160-163 still has the same sm/md both-at-text-base duplicate, so after this lands Textarea's md/lg/xl will visibly diverge from TextInput's at the same size. Worth a separate issue so the input family stays in lockstep.

_{barista · claude-opus-4-7 · 42 in / 4.2k out · 872k cached · 63s · $0.489}