fix(onboarding): normalize demo and input kinds in isOnboardingInputAllowed

[hsusul]

Fixes #1831

Problem

In src/helpers/onboardingInputPolicy.js:
isOnboardingInputAllowed used strict case-sensitive checks against ONBOARDING_DEMO_KINDS, returning false during onboarding demos if demoKind or inputKind had mixed casing or whitespace (e.g. "Dictation", "Assistant").

Solution

• Normalized demoKind and inputKind with trim().toLowerCase().
• Added unit tests in test/helpers/onboardingInputPolicy.test.js.

Verification

• node --test test/helpers/onboardingInputPolicy.test.js (passes, 5/5 tests)
• npm run typecheck (passes, 0 errors)
• npm run lint (passes, 0 errors)
• npm run i18n:check (passes)
• npm run build:renderer (passes)
• git diff --check (clean)

[Chadpiha]

Thanks for this, @hsusul! Closing along with #1831 — here's the reasoning.

demoKind can only ever be stored after passing two strict ONBOARDING_DEMO_KINDS.has() checks: once at the IPC boundary (onboarding-demo-begin in ipcHandlers.js) and again in windowManager.beginOnboardingDemo. Every inputKind call site is a hardcoded lowercase literal in windowManager.js, and the TS type is the exact union "dictation" | "assistant". So a mixed-case or padded kind can't reach this function in the app.

The strictness here is also deliberate: this is a fail-closed gate (there's even a test on main named "unknown demo kinds fail closed while onboarding is active"). Normalizing at the policy layer would make it looser than the two strict gates it sits behind, so a typo'd kind would be tolerated in one layer and rejected in two others — we'd rather it fail loudly and consistently.

Thanks for looking so closely at the onboarding flow — it's brand new (#1670), so extra eyes on it are very welcome!