FScrollPane arrow buttons stay on screen after their pane is hidden or torn down

[leriomaggio]

Describe the bug

FScrollPane's arrow buttons are not children of the scroll pane. FAbsolutePositioner.show()
adds them to a single shared JPanel with a null layout, parented to the window's
JLayeredPane, and positions them in window coordinates. They float above every screen.

They are removed from that overlay in one way only: FAbsolutePositioner.hide(), reached
from FScrollPane.hideArrowButtons(), which is called either from FScrollPane.setVisible(false)
or from the paint-time recompute in updateArrowButton.

Neither happens when a pane simply stops being painted. A container torn down with
removeAll() does not call setVisible(false) on its children, hiding a parent does not
call it either, and once the pane is no longer painted it cannot self-correct. The arrows
stay on the overlay at their last coordinates, over whatever is drawn next, including
completely different screens.

FAbsolutePositioner.hideAll() exists and would clear them, but it is only called from
SLayoutIO:402 on layout load and CHomeUI.itemClick:51, which fires when a submenu is
clicked in the left bar. Navigation that stays inside one submenu doc never reaches it.

To Reproduce

Steps to reproduce the behavior:

1. Open the online lobby and switch Play Mode to Limited
2. Set up an event, loading a pre-existing one whose name is long enough to overflow a
   panel horizontally
3. The lateral scroll arrow appears. Scroll fully right and the left arrow replaces it,
   so the arrows are working correctly at this point
4. Switch Play Mode back to Constructed. The arrow stays, in exactly the same position
5. Leave the lobby for the join-or-host screen. The arrow is still there, same position

Another way to reproduce this bug is in the Deck Editor:

1. Open the deck editor
2. Simply reduce the width of the filters panel to make arrows appearing
3. Switch to another tab (e.g. Deck catalog)
4. The arrows are still there, same position.

Expected behavior

An arrow button belongs to its scroll pane. When the pane is hidden, removed from its
container, or the screen it lives on is replaced, its arrows should go with it, and come
back on the next paint if still needed.

Smartphone (please complete the following information):

Not applicable. FScrollPane and FAbsolutePositioner are desktop only.

Additional context

Not specific to the limited lobby; that is just where it is easy to produce a wide enough
panel. Any arrow-capable FScrollPane that stops being painted should do it.

Suggested fix: have the pane clean up after itself rather than asking every caller to
remember. A HierarchyListener on SHOWING_CHANGED calling hideArrowButtons() when
!isShowing() covers all three cases at once, and the arrows return on the next paint,
which is already how they appear in the first place.