render: expand ChildList templates from the data model

[joestump]

What

Implements the dynamic-template form of ChildList. A container whose Children.Template is set now renders one instance of the template component per element of the bound data-model list, instead of the [a2tea: dynamic children not yet supported] placeholder. updateDataModel on the list grows or shrinks the children on the next render.

How

• render/template.go (new): renderTemplateChildren resolves Template.Path in the data model, converts the value to a list ([]any fast path, reflection for typed Go slices like []string), and renders Template.ComponentID once per element with that element pushed onto a scope stack.
• Element-scoped bindings: lookupBinding consults the scope stack innermost-first — an empty path or / is the element itself, and multi-segment paths traverse nested maps and numeric list indices — before falling back to the surface data model, so instances can mix per-element and shared values. dynString now routes through it; behavior outside templates is unchanged.
• Root/focus plumbing: childIDs counts the template component as referenced via the new childListIDs helper, so root derivation stays on the container and the focus walk reaches interactive components inside the template subtree.
• Edge behavior: unresolved path or empty list expands to no children (the list appears when data arrives); a non-list value renders a monochrome caption diagnostic in the existing [a2tea: ...] style. Cycle safety rides renderComponent's existing ancestor-path seen set (the Surface renderer falsely reports a cycle when a component is referenced by two parents #10 behavior): a template component referencing its own container reports a cycle per instance instead of recursing.
• docs/wire-format.md: moved ChildList templates from the "Not yet" list to implemented, with a description of the scoping rules.

Tests

render/template_test.go covers: template render with per-element bindings and ordering, grow/shrink via updateDataModel, empty and absent lists, cycle through the container, scalar []string elements with / self-binding (plus List bullet chrome), scope fallback to the surface data model, nested element paths, non-list diagnostic, root derivation with the template component declared first, and the static-ID form staying unaffected. go build ./... && go vet ./... && go test ./... all green.

Note: the website/ docs "Not yet" list (which links these gaps to backlog tickets) is deliberately untouched — it's deferred to the post-merge docs pass.

Fixes #44

🤖 Posted on behalf of @joestump by Claude.

[joestump]

Adversarial review of the ChildList template implementation against #44. Verified locally on the branch: go build ./... && go vet ./... && go test ./... all green, plus independent probe tests for cases the PR's suite doesn't cover (nested templates, a self-nested template component, buttons/textfields inside a template, JSON null at the template path).

Blockers

None found.

What I specifically hunted and confirmed correct:

• Scope stack correctness (render/template.go:27-38): push/pop around each instance is balanced, innermost-first lookup in lookupBinding handles nested templates correctly (verified: an outer /groups template containing an inner /members template renders all leaves with correct element scoping), and outside templates the stack is empty so dynString behavior is byte-identical to the old s.data lookup — including the "" key for / paths, matching applyDataModel's storage.
• Cycle safety: rides renderComponent's unwound seen set, so N sequential instances of the same template component are not mistaken for a cycle (the 3-element render test would fail otherwise), while a template component wrapping its own container — and even a component that is its own nested-template target (root -> grp -> grp) — reports [a2tea: cycle at ...] instead of recursing. Verified both.
• Root/focus plumbing (childListIDs): the template component counts as referenced in both rootID (NewSurface) and deriveRootID (applyComponents), and collectFocusables walks into the template subtree. TestTemplateRootDerivation genuinely exercises the declaration-order trap.
• []string handling: asList's reflection path converts typed slices element-by-element; the scalar-element test asserts real content and the List bullet chrome, not mere execution.
• No bypasses left: every ChildList consumer routes through renderChildren/childListIDs; the only remaining direct s.data read is editSeed, which runs at edit time when the scope stack is provably empty — equivalent.
• Test quality: assertions are behavioral (content presence, ordering via strings.Index, absence after shrink, placeholder leakage), not smoke tests. Grow and shrink are both asserted.

All four Done-when items are satisfied (docs update done in docs/wire-format.md; website/ correctly deferred to the docs pass per the workflow rule).

Nits (non-blocking)

1. render/template.go:31 — JSON null renders a producer-error diagnostic. updateDataModel {path: "/items", value: null} is a natural JSON idiom for clearing a list, but asList(nil) reports false (reflect.Invalid), so the surface shows [a2tea: template path "/items" is not a list] instead of expanding to no children. Consider treating a nil value like an unresolved path (return nil before the asList check) so agents can clear a list with null.
2. Shared focus across instances. An interactive component inside a template is one focusable ID: with 2+ elements, focusing it renders every instance in focused (reverse) style simultaneously, and activation/FieldValues carry no element identity. This is consistent with the surface's documented adjacency-list-reuse semantics ("one interactive element however many times it is drawn") and out of #44's scope, but it's worth a sentence in docs/wire-format.md's template paragraph so producers don't put buttons in templates expecting per-row actions.
3. resolveElementPath doesn't unescape JSON Pointer ~0/~1 tokens. Matches the pre-existing flat data model (applyDataModel doesn't either), so this is a consistency nit, not a regression — but if element keys can contain / or ~ it will misresolve. Same bucket: sub-path updates (/items/0/name) don't merge into the stored /items list; that's the pre-existing flat-model limitation, and template lists correctly respond to whole-list updates as the ticket requires.

Verdict: approve-quality. Nothing here ships a bug or misses the ticket contract.

🤖 Posted on behalf of @joestump by Claude.