Ensure right panel contents are unloaded when closed

[philrz]

What's changing

The change in this branch ensures that when the right panel is closed its contents are unloaded.

Why

Fixes #3128

Details

I traced the root cause of the failures described in #3128 to these two lines, which are in the table show details test.

zui/packages/zui-player/tests/right-click-menus.spec.ts

Lines 87 to 88 in a32bb54

	await app.rightClick('gridcell', 'conn');
	await app.click('listitem', 'Show In Detail Pane');

At that spot in the test, it's intending to right-click on the conn tile in the query results with intent to select the Show In Detail Pane option from the drop-down menu. However, the changes in #3127 caused a problem with this because, now that we have Inspector-style results in the right panel, that made a conn gridcell appear in the right panel that wasn't there previously (specifically, the one brought up in the prior test inspector show details) and hence the test might try to right-click it when the underlying locate() is performed to find the conn on which to right-click. Since the conn in the right panel can't be right-clicked, when the test happens to find and try to use that one, the no-op right-click causes the timeout in the test since the Show In Detail Pane never appears.

I verified this theory by trying my own hack fix first, which was to have the prior test (inspector show details) click a non-Detail tab in the right panel before closing the panel (I went with Correlations) since this had the effect of sweeping the conn-in-right-panel out of the way so it would not trip up the next test (table show details). Indeed, this was effective such that looped repeats of the right-click-menus.spec.ts tests no longer saw the intermittent failures described in #3128.

However, after showing this all to @jameskerr, he saw the cleaner fix would be to make sure the right panel contents are properly unloaded via the change that's now in this branch. Indeed, a looping repeat showed this fix to be effective as well.

Since #3128 prevented some recent advancements in the Zed pointer, I've gone ahead and advanced Zed in this branch as well.