cleanup: 6 safety fixes from clang-tidy worklist - #773

… s (amule-project#773)

The poll handler walks a round-robin, one step per timer tick, so at a 1000 ms tick across three steps any one step -- the stats request, or the active page's data -- came round only every ~3 s. The tick halves to 500 ms and the round-robin loses a step that did nothing but advance the index, whose body went away in 255dd95 once the stats packet started carrying the connection state.

The tick had to move because the handler only runs on a tick boundary: a wall-clock guard can only round up to the next one, so on a 1000 ms tick the achievable intervals were 1000, 2000, 3000 and nothing between.

This is a 3x increase in poll rate for those two requests. It is affordable because they are now incremental updates against the daemon's value maps, so a poll with nothing to report costs a near-empty reply. The daemon-side cost of serving EC_OP_GET_UPDATE does not shrink with the reply -- it still walks the file and client lists to compute the diff -- and at 0.34-2.05 ms measured on a production daemon that is roughly 0.03-0.2% of a core at 1 Hz.

Unaffected: the statistics tree still honours GetStatsInterval() and the ED2K link scan still runs at 1 s, both being wall-clock guarded; the reconnect timer is a separate wxTimer; the 30 s reply watchdog is wall-clock based.

The round-robin stays because two of its properties are load-bearing. It emits at most one step's worth of requests per tick, so independently-scheduled concerns cannot drift into alignment and burst against a request FIFO whose threshold is 20. And the fifo-full early return sits above the switch, so back-pressure pauses the cycle in place rather than leaving every concern overdue to fire at once on recovery. That matters most for EC_OP_STAT_REQ, EC_OP_GET_SERVERINFO and EC_OP_GET_CHAT_MESSAGES, which go out through SendRequest rather than DoRequery and so have no in-flight guard of their own.

…den (amule-project#817)

Losing the EC link put a modal reconnect dialog on screen whether or not the window was there to be seen. Minimised to the taskbar or hidden to the tray it appeared over whatever the user was actually doing and took focus, to explain a frozen window they could not see.

The dialog earns its intrusion by explaining that frozen window, so it now waits until there is one. With the window out of sight the retry loop runs exactly as before -- every attempt logged, the countdown ticking, the same 5 s spacing -- and simply draws nothing. Reconnect while minimised and the dialog is never created: the link comes back, polling resumes, nobody is interrupted. Return to the window mid-reconnect and it appears, opening on whatever the loop is doing rather than on "attempt 1", Abort button and all.

"Out of sight" means two things and neither alone is enough: minimised to Dock or taskbar keeps IsShown() true with nothing on screen, while hidden to tray leaves the iconized bit clear with no frame at all. CMuleTrayIcon::DoShowHide already had that pair spelled out inline to label its Show/Hide entry; it moves to CamuleDlg::IsVisibleToUser() and both callers share the one definition. Restoring is likewise two paths, because tray-hide never fires wxIconizeEvent and iconize never fires EVT_SHOW, so OnMinimize and OnShow each carry the hook. Neither shows the dialog directly: that would run a nested modal loop whose abort path calls Quit(), and tearing the main window down from a nested loop is what amule-project#738 was about, so it goes through CallAfter.

The retry machinery needed no changes -- AttemptReconnect, ScheduleNextReconnect and OnReconnectTimer already guarded every dialog access. What did need splitting is the tail of BeginReconnect, which assumed it was resuming after ShowModal returned; that work moves to FinishReconnect() so it runs whether or not a dialog was ever shown.

The dialog was never gated on window state, so what changed recently is how often it is reached rather than when it may appear: amule-project#768 made a silent link trigger a reconnect instead of freezing, and amule-project#773's move to ~1 s polling keeps a request outstanding far more of the time, which is that watchdog's precondition.

Iconize is not observable on Wayland (xdg-shell has no such notification), so compositors that never report it keep the old behaviour for the minimise case; the tray paths are unaffected.