Start input-sizing audit: planning doc + opt-in CSS CodeMirror mode

[amcclain]

Phase 1 of a systematic fix for the long-standing desktop-input sizing issues tracked in #3300, #4287, #4085, #2421.

What's in this PR

• docs/planning/input-sizing-audit.md — inventory of desktop + mobile inputs, root-cause mapping of all four tickets to two shared patterns ("default width wins over flex" and "layout props on wrong element"), draft sizing contract for later insertion into cmp/input/README.md, and a six-phase fix plan.
• desktop/cmp/input/modes/cssMode.ts — opt-in side-effect import that registers CodeMirror's CSS language mode on hoist-react's CodeMirror instance. Consumers import via @xh/hoist/desktop/cmp/input/modes/cssMode so webpack resolves codemirror through hoist-react's node_modules, sidestepping a duplicate-CodeMirror issue under inlineHoist dev mode (filed as inlineHoist: alias codemirror to dedupe with app copy hoist-dev-utils#67). First consumer is the matching toolbox test page.

What's not in this PR

No library code changes yet — this is intentionally audit + tooling only. The actual fixes follow in subsequent PRs per the plan:

• Phase 2: shared resolveInputLayout helper + flex-aware defaults (closes Desktop inputs require width: null to flex #3300, half of HoistInput default widths conflict with flex-based sizing #4287).
• Phase 3: outer-wrapper refactor for Picker / NumberInput / DateInput / SegmentedControl (closes other half of HoistInput default widths conflict with flex-based sizing #4287, plus Expose ability for dateInput to occupy the full width of its parent container #4085 and Extra <div> wrapper around DateInput DOM prevents setting className, styles on outermost element #2421).
• Phase 4: migrate pixel defaults from inline style to CSS.
• Phase 5: commit sizing contract into cmp/input/README.md.
• Phase 6: mobile parity check.

Companion PR

Toolbox admin test harness: xh/toolbox#842. Use it to confirm baseline and regression-check each library phase as it lands.

Decision to confirm before Phase 2

The audit doc surfaces three paths for how we deliver "nice out of the box":

• A. CSS defaults, overridable by cascade (closest to current; minimal breakage).
• B. Flex-aware default (suppress inline default when flex/minWidth/maxWidth/width:100%/null is present).
• C. No pixel default, match MUI/Ant/Chakra/Mantine (largest behavior change).

Recommended: A with B's guard as a safety net. Revisit C in a later milestone if we want full convergence with mobile + library norms.

[amcclain]

@TomTirapani I am eager to pick this up in our next release - see the toolbox branch for a new admin-client based input testing tool that I think came out very well. We will need to proceed with care in terms of implementing the plan here - there are no changes yet - but I think it's a good time to finally improve and fix our story around sizing desktop inputs.

Would love your "input" if you have a chance to look at any point. 😄

[TomTirapani]

Finally had time to read this, think it all makes sense and is certainly a worth endeavour! Agree with the assessment the approach A (move default widths to stylesheets rather than inline) makes the most sense for out-of-the-box defaults - think that has the lowest chance of introducing issues in client usages, and is easy to reason about all round.