fix: keep ui.Template a value, holding its state on the Element

[linkdata]

Fixes the container-reuse regression #221 introduced.

The regression

ContainerHelper.reconcile keys its reuse pool on childElem.UI() — value equality. #221 gave ui.Template per-Element ownership state, which forced it to become a pointer, so a container whose JawsContains rebuilds ui.NewTemplate(...) children on every call stopped matching the pool. Every update removed and re-appended the entire collection: new Jids, full DOM churn, browser work proportional to the collection rather than to the change.

No test caught it, which is why it shipped. TestContainer_RebuiltTemplateChildrenAreReused is that test: it asserts child Jids are unchanged across updates and that an unchanged collection queues no Append/Remove/Order. Re-pointerising NewTemplate in a throwaway worktree fails it on the first update (child 0 Jid = Jid.5, want Jid.2).

The fix

The Element is the natural home for state keyed to an Element, so core gains one slot for it and Template goes back to a plain comparable value.

func ElementState(elem *Element) (state any)
func SetElementState(elem *Element, state any) error   // ErrElementStateClaimed / ErrElementStateNil

Design points that took some working out:

• Loading and claiming are separate, so contention is reported rather than absorbed. A get-or-create returning the occupant would silently let a second Template mutate the first's generation and delete Elements it doesn't own. A second claim fails even for state of the same dynamic type — same type is not the same owner.
• Nil is rejected. data any uses a nil interface to mean unclaimed, so accepting SetElementState(elem, nil) would report success while leaving the slot claimable, hollowing out claim-once. A typed nil is a non-nil interface and does claim the slot. The nil-argument check precedes the occupancy check.
• Package-level, not methods. ui.With embeds *Element and ui.RequestWriter, so any method returning a value is callable from a template; {{$.Element.SetElementState $.Dot}} would let a template claim the slot out from under its renderer. html/template cannot call a package-level function.
• Claiming happens only in JawsRender, before tag registration, handler registration and any write, so a contended Element fails having changed nothing — asserted, not just claimed.
• execute takes the state as a parameter. pageTemplate.JawsRender bypasses render, so without that the page's nested UI would have been tracked by nothing at all; making it a parameter means the compiler asks each entry point.
• The ownership walk matches *templateState specifically, not any elementOwner. The slot legitimately holds whatever a renderer put there, so a typed nil satisfying elementOwner through a promoted method — (*ui.Container)(nil) — would have been dereferenced during a parent Template's cleanup.

Released behaviour that narrows

Both follow from Template previously being stateless, and both are in the commit message for release notes:

1. Any repeated Template render on one Element now fails the second claim with ErrElementStateClaimed — two distinct Templates, two equal ones, or the same value twice. Renderer.JawsRender permits delegation, so a composite renderer emitting several unwrapped partials this way was legitimate. Migration: combine the partials under one claiming Template, or give each its own Element, which a nested {{$.Template ...}} already does.
2. A wrapped Template's JawsUpdate without a claim reports ErrElementStateUnclaimed through MustLog — which panics when no Jaws.Logger is configured, not a silent no-op. So a wrapped Template cannot be a Register/NewRegister/RequestWriter.Register updater. An unwrapped one still can: its updates are a documented no-op, though only RequestWriter.Register also delivers its event handlers, since Register embeds jaws.Updater and promotes no handler methods.

Delegated rendering and updating must use the same UI widget. For Template values, that means values equal under ==; using an unequal Template value for JawsUpdate is unsupported. Element state storage does not relax that lifecycle contract.

The MustLog outcome differs by call path and is tested per path: a template action has its panic recovered by html/template into a render error; a direct rw.Register call lets it escape; on the request loop Request.process consumes it and tears the request down, with TestServe's callback seeing nil precisely because process already consumed it.

Numbers

-benchtime=200x -count=6, arm64, baseline pinned to 9b02d46 and every benchmark name verified present in both outputs before benchstat:

ContainerOfTemplatesUpdate   (200 rebuilt children, unchanged collection)
  sec/op     1220.08µ ± 3%  ->  73.62µ ± 35%   -93.97% (p=0.002 n=6)
  B/op        194.93Ki ± 0%  ->  28.48Ki ±  0%  -85.39% (p=0.002 n=6)
  allocs/op     4046.0 ± 0%  ->    406.0 ±  0%  -89.97% (p=0.002 n=6)

ContainerOfStableChildrenUpdate  (already reusable before this change)
  sec/op        31.19µ ± 12%  ->  28.53µ ± 11%   ~ (p=0.132 n=6)
  allocs/op      205.0 ±  0%  ->   205.0 ±  0%   ~ (all equal)

ElementCreateBatch  (corrected timer; the cost every Element pays for the slot)
  sec/op         2.077µ       ->   2.240µ         +7.87% (p=0.002 n=6)
  B/op          4.000Ki       ->  5.000Ki        +25.00% (p=0.002 n=6)   # 16 B/Element
  allocs/op       64.00       ->     64.00          ~ (all equal)

TemplateUpdateOwnedCleanup/children=1000  (each rendered Template allocates its state)
  sec/op         3.650m ± 2%  ->  3.708m ±  2%   ~ (p=0.180 n=6)
  allocs/op      26.79k ± 0%  ->  27.79k ±  0%  +3.73% (p=0.002 n=6)

The two costs are real and measured rather than assumed: two words per Element for the slot, and one allocation per rendered Template for its state. Both are dwarfed by the container fix, and the cleanup path's time is unchanged. Small-generation cleanup variants (0 and 8 children) are included because the 1000-child case swamps any fixed per-update cost.

Also

• TestElementState_* cover claim-once, both sentinels and their precedence, typed nil, per-Element independence, and concurrent claims under -race with exactly one winner.
• Rendering delegation tests verify that a delegator's own child survives the Template's rollback, and that a claim persists after a handled render error so an equal Template value can later update the Element. Delegating JawsUpdate to an unequal Template value is unsupported.
• Two existing tests needed real migration, not just an added render: TestTemplate_UpdateLogsExecuteError's template always fails, so it moves to a render-succeeds-then-update-fails fixture, and TestTemplate_RenderUpdateEventAndHelpers updated an unrendered Template with no logger, which would now panic.
• Docs: UI multiplicity keeps its concrete-type opt-in rule (statelessness alone grants nothing), Renderer.JawsRender gains the delegation note, and lib/ui/doc.go's canonical classification moves Template back to the value/multi-Element group. The public API, README and tracked jaws skill now state the same-widget update contract, exact Dot dynamic-type and nil-interface rules, Register's updater-render behavior, and the unenforced Element provenance precondition.

Not addressed here, deliberately: tag resolution/snapshotting (#224) and generalising per-Element state to the other by-value widget candidates (#225).

Gate run locally in build.yml order: go generate (tree unchanged), go vet, gofmt, staticcheck, golangci-lint (0 issues), gosec, both test legs with JAWS_REQUIRE_NODE=1, coverage (lib/ui still 100%), go build -v, the debug-tag leg, and go doc on every symbol whose contract this touches. The 386 job cannot execute on this arm64 host, so it was verified by compiling.