Undo history in a webview viewer must start from an empty baseline, or the first change can never be undone

A bug pattern, seen in a host integration around the VaporView waveform webview, that applies to any editor that mirrors a webview's state for undo. The host pushed the previous context onto its undo stack only when it already held a context: if (webviewContext) undoStack.push(webviewContext). On a freshly opened viewer that context is null until the first state update arrives, so the very first user change (e.g. adding a signal) was never recorded, and Undo did nothing for it. Later changes undid normally, which hid the bug. Upstream's document model avoids this by starting with an empty state object and always capturing it before each change.

Fix: when there is no context yet, push an explicit empty baseline (ideally the same defaults the viewer starts with, not just an empty list, so Undo also resets marker and zoom). Keep restore and initial-load updates out of the undo stack.

Test so the result can be trusted: count what the viewer actually draws (DOM rows), not what the page reports. In this case a self-reported state echo made a reload test pass on the broken code.