Move dynamicComponent into solid-js (keep dynamic in @solidjs/web, re-export for compatibility) #3907

Problem

dynamicComponent is a renderer-agnostic primitive, but it lives in @solidjs/web. So universal and custom renderers can't use it without depending on web. Moving it is byte-neutral: the code changes packages and stays tree-shaken.

In both web entries, dynamic and dynamicComponent are thin wrappers over one dynamicCore(source, options, tagArm?):

• Client: packages/web/src/index.ts. dynamic = dynamicCore(source, options, staticElement) (341–346). dynamicComponent = dynamicCore(source, options) (380–385). dynamicCore is at 402–579 and staticDynamic at 584–601.
• Server: packages/web/src/index.server.ts. dynamic passes ssrTag (116–121, 140–141), dynamicComponent passes nothing (131–136), and dynamicCore is at 145–277.

The tag arm is injected as a parameter on purpose, so a bundle that only uses dynamicComponent drops the element runtime. That is the only DOM- or SSR-specific part. Everything else depends on solid-js alone:

• Client core: createMemo, createSignal, onCleanup and untrack, plus sharedConfig and $DEVCOMP from solid-js/internal. It also uses web's isDev constant, which maps to core's IS_DEV.
• Server core: createMemo, untrack, NotReadyError and sharedConfig.context.block. Its classifyLanding (311–336) raises DYNAMIC_ASYNC_COMPONENT through web's recordFinding/IS_OBSERVE; packages/solid/src/server/diagnostics.ts already exports recordFinding, IS_DEV and IS_OBSERVE.
• Server-component markers: the binding marker is Symbol.for("solid.component-binding") (index.ts:291, matching frames/src/frame-transport.ts:373). The server-component brand is Symbol.for("solid.server-component") (index.server.ts:294). Neither needs an import from frames.
• FLIGHT: a module-local Symbol("solid.dynamic-flight").

So core needs no knowledge of the frames transport. It keeps duck-typing the same global symbols.

Proposal

• Move dynamicCore (taking an optional tag arm), staticDynamic, bindingOf, FLIGHT, classifyLanding and DynamicOptions into solid-js. Add them to both the client build (src/client/) and the server build (src/server/), the same way as lazy.
• Export dynamicComponent from solid-js.
• Export the tag-arm core from solid-js as @internal. Read it back through solid-js/internal, the same way createLoadingBoundary/createErrorBoundary are today (packages/solid/src/internal.ts).
• @solidjs/web keeps dynamic = core + staticElement (client) or ssrTag (server), and keeps Dynamic (built on dynamic, not dynamicComponent). It re-exports dynamicComponent from solid-js.

What moves with it

• Types: packages/web/types/index.d.ts:150 and index.server.d.ts:54 currently disagree: the client source type accepts AsyncIterable<C>, the server's doesn't. solid-js ships one types/index.d.ts for every condition, so one signature has to be picked (presumably the client's). ComponentProps<C> for C extends Component is the same in core and web.
• Tests: packages/web/test/dynamic-component.type-tests.tsx, server/dynamic-component-parity.spec.tsx, hydration/dynamic-component-parity-*.spec.tsx, harness/dynamic-component-parity.tsx, frames-errored-reset-refetch.spec.tsx, and consistency/c16-*/c17-*. The parity tests check dynamic and dynamicComponent against each other, so they probably stay in web and import both.
• Docs and size scripts: documentation/solid-2.0/03-control-flow.md, 10-server-functions.md, 11-server-components.md, documentation/server-components/*.md, and the dynamicComponent imports in scripts/size/ fixtures and scenarios.

Cost

• Apps that don't use it pay nothing; it's tree-shaken like lazy.
• Apps that use it pay the same bytes as today — the code only changes packages.

Open questions

• Should the server DYNAMIC_ASYNC_COMPONENT check stay in core as is? Its message refers to dynamic().
• Should dynamic move too, with the element tag arm passed in? Probably not: the tag arm needs the element runtime, and that is the reason it lives in web.