Render: instance elements are skipped when the subcomponent is missing from the instance manifest

[nathanacurtis]

Found while verifying #259 across the specs-testing render round-trip corpus.

Symptom: rendering a spec whose elements reference a subcomponent by name drops those elements entirely when the name has no entry in the instance manifest. The render still reports success — the only signal is a console warning:

⚠ [writer] instance element "dsButton": no manifest entry for "dsButton" — skipping
⚠ [writer] instance element "instance1": no manifest entry for "laidOutComponent" — skipping
⚠ [writer] instance element "instance2": no manifest entry for "laidOutComponent" — skipping

Everything on the skipped node is lost with it — sizing, dimensions, propConfigurations — so the round-trip reads as broad fidelity loss that is really one missing lookup.

Reach: 3 fixtures in the current corpus.

• testStylesSizing (dsButton)
• testElementsNestedInstances (dsButton)
• testElementsNestedInstancesLayout (instance1, instance2 → laidOutComponent)

Where: the manifest lookup in Elements.createChild bails before any node is created, so no sizing or style code is involved.

Notes:

• A silent success is the worst part — the render exits 0 and the loss surfaces only on a diff.
• Worth deciding whether a missing manifest entry should fail the render, or resolve the subcomponent on demand the way Component.write already writes subcomponents before their dependents.

Verification: round-trip the three fixtures above; their instance elements must survive with sizing intact.

Part of #204.

[nathanacurtis]

Closing — the evidence behind this issue was invalid.

All three fixtures were round-tripped through the specs-testing harness while its run directory carried an empty specs/. The bridge scans that directory to build the instance manifest, so every render reported Manifest: 0 entries and every instance element in every component was skipped, regardless of engine behaviour. The diagnosis here — "the manifest lookup in Elements.createChild bails before any node is created" — is accurate but describes the symptom of an empty manifest, not a defect in the lookup.

The harness has been fixed (its run directory now symlinks the source workspace's specs/, and the whole run directory is cleared per run so nothing leaks between sessions). Manifest goes from 0 to 69 entries on the reference workspace, and nested instances render.

On the two named dependencies:

• dsButton — a dsButton spec existed in workspaces/specs-testing/specs/ and was later deleted. Corpus drift, not an engine defect.
• laidOutComponent — appears only in the fetched file's top-level components map, not in the document tree. That map lists components referenced by the file, including ones owned by other libraries, so this is reference pollution rather than a component that can be resolved.

Also worth recording, since it was proven correct along the way: a component's own subcomponents already work as intended. Component.write writes them first (topologically sorted, leaves before dependents) and Subcomponents.write registers each freshly-created node under both its map key and its formatted title, so a rendered component instances the newly rendered subcomponents and never the old library nodes.

One observation from this issue does survive, independent of the harness, and is tracked separately: a render that cannot resolve an instance drops it, warns to the console, and still exits 0. Genuinely external dependencies (another library's components) will never resolve, so that is a permanent steady state rather than a corpus problem.