automation bridge: hover verb ignores x/y, so point-hover tooltips aren't provable

AutomationServer::doHover always synthesizes the QEnterEvent + QMouseMove at w->rect().center() and ignores any x/y the caller passes (src/core/AutomationServer.cpp, doHover).

That is fine for the widget-level hover states it was written for (the HGauge readout), but it means any hover behaviour that depends on where in the widget the pointer is cannot be driven from the bridge. Concretely, reviewing #4828 I could prove the KiwiSDR DX spot markers render and that clicking one tunes the slice, but not that hovering one shows its tooltip — the markers are 5 px wide on the band-plan strip and hover can only reach the widget centre.

The same gap applies to the existing band-plan spot tooltips, panadapter cursor-frequency readout, spot-label hover, and TNF hover.

Ask

1. hover <target> [x y] — honour local coordinates when given, keep centre as the default so existing callers are unaffected.
2. A way to read the currently-showing transient tooltip. QToolTip::showText creates a QTipLabel top-level that dumpTree does not surface, and the existing tooltip verb only reads a widget's static toolTip property. Either surface QToolTip::text() from a new verb or include tooltip windows in dumpTree.

With both, a tooltip assertion becomes hover pan0 <x> <y> + read-back, which is what several open overlay features need in order to be proven rather than eyeballed.

Start in src/core/AutomationServer.cpp at AutomationServer::doHover, then inspect the existing tooltip verb and dumpTree behavior. Trace how hover coordinates and transient QToolTip windows are currently handled. Done means hover accepts optional local x/y while retaining the center default, and a transient tooltip can be read back through one of the proposed surfaces.