[Tiaxi]

Closes #574.

What changes

When the pointer left the seek bar, its hover position and second reset to 0 in the same change that hid the time tooltip. Under Breeze the tooltip fades out, so it faded at the bar's start, the 0:00 position, and could read 0:00.

• hoverX and hoverSecond keep their last values while hidden (Binding … when: hoverTimeShown, RestoreNone), so the tooltip fades out where it was, with its time. Hidden, nothing follows the pointer or playback, so no hidden change draws frames.
• When the length becomes unknown, the slider's range falls back to a stand-in (to: 1.0). hoverSecond keeps the last second then, rather than recomputing against that range before hoverTimeShown has caught up, which latched 0:00.
• The tooltip's anchor and text take their source from the gesture's and the hover's own state: gestureHeld(), which adjusting now uses too, and seekHover.hovered. They don't wait on shown/adjusting, which can still hold their old values within the same change. With neither a gesture nor a hover, the anchor stays where it was. So a touch drag, which has no hover, fades out beside the playhead with its time, instead of jumping to the last hover position (or 0).
• seekHoverLine still reads hoverX. It's hidden whenever the held value would differ, and fix: show the seek bar's playhead for very short tracks #552's short-track handling is unchanged (any length > 0 counts as known).

Tests

AccessibilityTest::seekTimeFadesOutWhereItWas runs in the app's own style (org.kde.desktop), whose ToolTip has an exit transition. On every frame of each fade-out it checks that the box's x and text stay as shown, and it uses signal spies to catch even changes that no frame draws. Cases:

• hover mid-bar, then leave
• a hover elsewhere, including one that comes back during a fade, shows its own time at its own place
• a mouse drag shows the playhead's time beside the playhead, and the hover's time returns where the drag ends
• a touch drag's release fades beside the playhead
• Stopped (seekAllowed false) while hovering fades in place, and Playing shows it again
• a track change to another length shows the new time under the pointer, and a change to an unknown length fades in place

Without the fix, the test fails at the first leave: the box moves to x = -18, the 0:00 position, for the whole fade. With only the hover hold, the unknown-length case still latches 0:00, and the touch case changes its text.

./scripts/run-tests.sh --ui-only: 104/104 passed.

Not covered here

A mouse drag that is released off the bar still fades out at the hover point from before the drag, with that point's time. Qt doesn't update HoverHandler during a grab, and leaves it stale until the frame after the release. So at the release the hover still counts as on the bar, and its stale point takes over before the next frame hides it. This was already the case before this PR, only at x = 0. It needs a fresh hover state after a gesture, so I left it as a possible follow-up.