Bug: Small API thing -- cycling docs with API does not also cycle to corresponding plugin

Nobody has claimed this yet.

Here's a small window layering issue which I'm quite sure used to be gone but has resurfaced:

In the editor window, using ctrl+Tab to cycle open (tabbed) documents will bring its corresponding plugin window to the front. Good and expected.

Previously, cycling tabs from within FTOutliner with `Beat.nextTab()` and `Beat.previousTab()` would do the same — but since some time back, this only cycles the document and not the plugin window (i.e. keeps focus in current plugin).

Related or not: If invoked when plugin is focused (hitting `cmd+O` etc) Beat dialogs like Open and Save will open behind the plugin window. Also, if crashing Beat when running from xCode, the dead plugin window lingers on top of everything obscuring the xCode controls, almost as if plugin Windows been set to uconditionally float on top?

That's all.

Start with the FTOutliner entry points Beat.nextTab() and Beat.previousTab(), then compare their behavior with ctrl+Tab in the editor window. Done means cycling documents from FTOutliner also brings the corresponding plugin window forward; separately verify the reported dialog and crashed-plugin window focus behavior if those remain in scope.

Written by the indexing model from the issue text.