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

**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.