fix(coordinator): build all split panes through one path so a new tab's inspector renders

[datlechin]

Problem

The row detail (inspector) panel stays blank when a table is opened in a second native window tab. Selecting any row in that tab shows nothing; the panel only fills in once the inspector is manually toggled. Opening the same table as the first tab works fine.

Root cause

MainSplitViewController built its three panes in two places that had to be kept in sync by hand:

• viewDidLoad built the sidebar and detail panes from their buildX() views, but hardcoded the inspector to a Color.clear placeholder, deferring the real inspector to a later rebuildPanes() call.
• rebuildPanes() (only called from the session-config path) built all three for real.

When a table opens as a second tab (joining an existing tab group), the session is already available at viewDidLoad, so the session-config path early-returns via its isContentViewEquivalent guard and rebuildPanes() never runs. The inspector host is left as Color.clear. The pane is visible (its split item isn't collapsed, restored from the per-connection split autosave) but hosts nothing, so row selections update RightPanelState.inspectorContext with no view mounted to render them.

The first tab works because at its viewDidLoad the session isn't ready, so rebuildPanes() runs later and installs the real inspector.

Fix

Make rebuildPanes() the single source of truth for pane content. viewDidLoad now builds only the split structure (hosting controllers with neutral placeholders, split items, autosave, collapse state) and then calls rebuildPanes() to install all content. Because viewDidLoad always calls it, every pane (including the inspector) always gets its real view, regardless of whether the session was ready at load. A pane can no longer be left as a placeholder, and the two build paths can't drift again.

This also removes the duplicated sidebar/detail/inspector build calls and sidebar-state wiring that previously lived in both methods.

How it was found

Added temporary OSLog tracing across the selection -> inspector-context -> view-render chain and reproduced with two tabs. The logs showed the new tab's RightPanelState.inspectorContext updating on every click while its UnifiedRightPanelView never rendered and rebuildPanes() never ran for that window. The tracing has been removed.

Testing

The failing value (Color.clear placeholder vs the hosted UnifiedRightPanelView) is wrapped in an opaque AnyView and not introspectable, and a UI test would depend on a live connection, native tab-grouping, and per-connection inspector autosave state, none deterministic in CI. Verified manually: open a table, open a second table in a new tab, select a row -> the detail panel now shows the row immediately.