[BUG]: Legacy Lit renderer spreads server-controlled property names verbatim onto elements (`el[prop] = val`)

# Legacy Lit renderer spreads server-controlled property names verbatim onto elements (`el[prop] = val`)

Repository: https://github.com/a2ui-project/a2ui
Affected: `@a2ui/lit` (verified against published npm release 0.10.3), legacy 0.8 path
CWE: CWE-915 (Improperly Controlled Modification of Dynamically Determined Object Attributes)

## Summary

In the 0.8 `Root.renderComponentTree`, when custom elements are enabled, the renderer assigns every key of the server-supplied `component.properties` object directly onto the freshly constructed element — with no allowlist. The code itself flags the bypass (`// @ts-expect-error We're off the books.`). The server chooses the element (`component.type` resolves through `customElements.get()`) **and** every property name, so assignments reach sinks such as `innerHTML` (HTML parsed on commit — injected ``), `outerHTML`, `src`/`href`/`srcdoc`, `is`, `formaction`, and app-defined setters. `Object.entries` skips `__proto__`/`constructor`, so the loop itself is not a prototype-pollution vector; the defect is unrestricted attribute/property modification.

Precondition (honest): both spread sites are gated by `enableCustomElements === true` — a developer opt-in, not server-flippable. On stock `a2ui-*` elements, `innerHTML`-onerror races the element's own microtask light-DOM wipe (timing-fragile); the reliable target is an application-registered custom element that keeps its light DOM (e.g. exposes a ``). This is the Lit counterpart of the Angular sample-renderer bypass reported as F-04, in a different renderer and via a different mechanism (property spreading vs sanitizer bypass).

## Affected code

- `@a2ui/lit` `src/0.8/ui/root.js:211-215` (inline `enableCustomElements` branch) and `:544-548` (`renderCustomComponent`, default switch case):

```js
for (const [prop, val] of Object.entries(component.properties)) {
// @ts-expect-error We're off the books.
el[prop] = val;
}
```

## Observed behavior

Static verification (verbatim quote above; headless harness has no browser DOM, so no runtime PoC). Reachability of the spreading branch confirmed by reading `surface.js:182` (`enableCustomElements` propagation) and `root.js:195/525` (the two gates).

## Impact

Wherever the opt-in is enabled and any slot-bearing/app-registered element exists, an agent turns one `updateComponents` message into arbitrary HTML/script injection (`innerHTML`) or request forgery (`src`/`href`/`formaction`). XSS-class impact, conditional on the documented opt-in.

## Suggested remediation

- Replace the loop with an explicit per-element property allowlist; at minimum deny `innerHTML`/`outerHTML`/`srcdoc`/`is`/`formaction`/`href`/`src`/`on*`/`style`/`data-*` against arbitrary server keys.
- Prefer routing all server props through the v0_9 binder schema path (which the v0_9 catalog already does safely via `.context`).