Phase 1b: Per-platform template keying + P0/P1 sizing sweep

[Shewart]

Summary

Closes out Phase 1b of the ShellUI Native roadmap: the template layer becomes
platform-keyed so adding Avalonia (Phase 2) is a per-template dict entry rather
than a whole parallel registry. Also lands a P0/P1 correctness/consistency sweep
of the existing MAUI templates.

Prerequisite for Phase 2 (Avalonia implementation).

Phase 1b — Template System v2

Problem: ComponentRegistry.GetComponentContent(name) returned a single
MAUI-flavored C# string per component. There was no platform dimension in the
lookup path — Avalonia would have needed either a duplicate registry or install-time
string-mangling of MAUI templates.

Design: per-template Contents dictionary owned by the template class; the
registry stores (Metadata, Contents) bundles so lookup is one hop with no
per-component switch arms to maintain as new platforms are added.

• All 44 templates migrated from public static string Content => to
  public static IReadOnlyDictionary<NativePlatform, string> Contents { get; }
• ComponentRegistry.GetComponentContent(name, NativePlatform) — returns
  null for known component + unsupported platform (distinguishable from unknown
  component via new SupportsPlatform / GetSupportedPlatforms)
• New UnsupportedPlatformException in Core.Models with ComponentName,
  RequestedPlatform, SupportedPlatforms for programmatic callers
• ComponentInstaller / ComponentManager / InitService all thread
  config.TargetPlatform through and skip components that don't support it,
  with a clear error listing supported platforms
• Blanket "MAUI-only" install-time warning removed; per-component platform check
  replaces it (silent when the platform IS supported)

P0/P1 sizing + token sweep

Full re-read of every P0 + P1 template looking for the class of drift the Input
component had. Three real bugs found and fixed; everything else surveyed
(Badge, Progress, Alert, Card family, Label, Separator, Switch, Checkbox, Shell,
Dialog/Drawer/Sheet/Popover content boxes) was sized and tokenized correctly.

1. Input height drift — Border had no HeightRequest and used
Padding = (12, 8), so the composite grew to whatever platform-default height
Entry picked (Windows ~44, Android ~48+ with material padding). Rendered
visibly taller than the pickers sitting next to it in the same form row. Now
HeightRequest = 40 and Padding = (12, 0), matching Select / DatePicker /
TimePicker.

2. Primary-blue token drift — InputTemplate focus border and
RadioGroupItemTemplate checked indicator used #3B82F6 (blue-500) while
Button / Checkbox / Switch / Progress all use #2563EB (blue-600) for
the same "primary" role. Standardized on #2563EB.

3. DropdownItem hit target too small — Padding = (8, 10) with no minimum
height → ~34px rows, below iOS 44px / Android 48dp touch guidance. Now
Padding = (12, 12) + MinimumHeightRequest = 40.

4. RadioGroupItem checked-border missing — only the fill flipped color when
a radio became selected; the ring stayed grey. Checkbox had already handled
this. Fixed to match — both stroke and background flip to #2563EB when checked.

Docs

• COMPONENTS_ROADMAP.md — new Form Sizing
  Contract section (per-control height/padding table + rules for future
  controls, menu rows, and icon-shaped controls) and new Design Token
  Contract section (every ARGB in use mapped to its role, so drifts like
  the two blues can't sneak back in and Phase 2's Avalonia ResourceDictionary
  extraction is mechanical)
• ARCHITECTURE.md — documents the platform-keyed
  registry lookup and the SupportsPlatform / GetSupportedPlatforms contract
• DEVELOPMENT_PLAN.md — new living doc tracking
  branch strategy, phase status, and Phase 1b follow-ups

Test plan

• dotnet build src/ — 0 warnings, 0 errors
• dotnet test — 199/199 passing (up from 147; 52 new/updated tests
  covering the platform-keyed registry, UnsupportedPlatformException, and
  regression locks that will fail-loud when Phase 2 adds Avalonia content)
• TemplateContentTests parameterized over all 44 components on
  NativePlatform.MAUI — every existing MAUI template still compiles identically
• Every_component_reports_MAUI_as_a_supported_platform — regression lock
• GetComponentContent_returns_null_for_known_component_but_unsupported_platform —
  verifies the null-return contract for the Avalonia case that will flip once
  Phase 2 adds content
• Manual visual pass in MAUI.Demo on Windows/Android/iOS heads to confirm
  Input / Select / DatePicker / TimePicker render at the same 40px height side by
  side (not yet automated)
• Manual shellui-native init --yes && add button input card dialog against
  a fresh dotnet new maui project — needs a workstation with the MAUI workload
  installed

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.