easel: a vendor CLI talking to a person is not a protocol error master
`prox:ruzomo` was reporting a JSON parse error in a session that had not run a turn yet. Both bridges read the child's stdout a line at a time and JSON.parse every one of them, and anything that failed became `invalid engine message: Unexpected token …` in the transcript. But a vendor CLI writes to stdout for two audiences. The protocol goes there, and so do the notices meant for whoever is watching — the connector warning, the model-catalog complaint. Neither was ever addressed to us, and both were being shown to the user as errors in their own session. A line that opens with a brace or a bracket was meant to be JSON, and failing to parse that is a real fault worth surfacing. Anything else is the CLI talking, and now goes to the log beside the stderr it would have used had it picked the other pipe. slab-web: previews open small, and two AC defaults are tuned for a full screen. The system paints its corner label at (6, 6) so a visitor can get back; in a tile a few hundred pixels wide that is a sizeable share of the frame and there is nowhere to go back to. `nolabel` reclaims it — verified on a real piece, not assumed: the label is gone and the corner buttons with it. And density is an upscale factor rather than a resolution, so a higher number means fewer, larger pixels. The name reads backwards and I read it backwards: "lower density" wants a *higher* value. Measured at 420x300 — 0.5 illegible, 1 readable, 2 comfortable — so previews get 2, overridable with SLAB_WEB_DENSITY. Only aesthetic.computer and prompt.ac get the parameters; a file:// study or any other URL has no idea what they mean, and an existing query string is extended rather than replaced. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>