fix: re-trigger lineage render on webview:ready to close postMessage race (#1931)

When the lineage webview first mounts, the extension posts an initial
`render` from `init()` before the React `window.addEventListener('message', ...)`
in `LineageView.tsx` has been registered. VS Code's webview API queues
postMessages until the iframe's HTML is ready, not until React's effects
have run, so the initial render can be silently dropped.

The webview already attempts a recovery via `executeRequestInAsync('init', {})`
once its listener is registered, and PR #1857 added an `eventMapChanged`
re-render path. Both close *some* races, but neither covers the case where
the recovery `init` is delayed past where the user perceives the panel as
broken (a known telemetry signal: `Lineage:getStartingNode` "No event found"
fires 811 times across 84 distinct machines in the last 7 days, with the
top offender hitting it 93 times in a 35-minute single session).

This adds an explicit `onWebviewReady` override on `NewLineagePanel` that
re-runs `renderStartingNode()` once the framework-level `webview:ready`
ack arrives. By that point both `useListeners` (AppProvider) and
`LineageView`'s own message listener have registered, so the second
render lands. The webview-driven `init` recovery and the manifest-change
re-render remain in place as additional belts.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: ralphstodomingo

src/webview_provider/newLineagePanel.ts

@@ -92,6 +92,11 @@ export class NewLineagePanel
     this.renderStartingNode();
   }
 
+  protected onWebviewReady() {
+    super.onWebviewReady();
+    this.renderStartingNode();
+  }
+
   changedActiveColorTheme() {
     if (!this._panel) {
       return;