layout: narrow keyed field parts.control by widget (#176)

[timkindberg]

Reaching a field through layout's keyed door still made you write a c.kind guard, even though the brand already knew the widget. Found this while reviewing #174.

<Default
  of={root.children.username}
  parts={{ control: (c) => <input {...c.attrs} /> }} // no guard now
/>

• LayoutNode's field branch is a new LayoutField — an EField with parts.control Extracted down to ControlForWidget<TS['fields'][Path]['widget']>
• ControlOverrideOf already preferred a handle's live parts.control over Core's wide PartsOverrides, so nothing else needed wiring
• Widget overrides re-narrow for free — useFormTree already re-brands form through ApplyWidgetOverrides
• New test renders an input + a choicegroup through guard-free parts.control, with a @ts-expect-error proving the narrowing. Four existing layout assertions moved to toExtend since the handle is a subtype now
• Amended ADR 055's consequence bullet, which used to say widget narrowing stays the intercept-rules job

The function intercept door keeps the full union on purpose — it fires for every node so it genuinely can't know more (ADR 029 §5). Unbranded trees keep AnyKindNode.

npm run gate green.

Closes #176