panel: retry restoring panels whose monitor lags behind monitors-changed

[sergiuko83]

What

PanelManager._onMonitorsChanged() currently tries to recreate a panel
whose monitor previously went missing exactly once, synchronously, when
monitors-changed fires. This adds a small bounded retry (1s, 2s, 4s) for
any panel still missing after that first pass, scoped only to the affected
panel IDs.

Why

Some outputs - USB-C / DisplayPort-alt-mode adapters in particular -
finish link training and EDID negotiation slower than native HDMI/DP. If
monitors-changed fires before the monitor is fully enumerated,
global.display.get_n_monitors() is still stale, the existing single
restore check fails, and nothing tries again automatically. The panel's
metadata is preserved (so it isn't destroyed), but the panel stays
invisible until the user manually adds a new panel on that monitor -
which happens to reuse the existing metadata - or an unrelated hotplug
event happens to fire monitors-changed again.

Reported independently by multiple users in #12467, on hardware ranging
from docking-station USB-C setups to direct USB-C adapters, across
multiple Cinnamon versions (6.2.9 through at least 6.4.6), so this isn't
tied to one specific driver stack.

How

_scheduleMissingPanelRetry(id) is called only for panels that fail the
existing restore check. It re-checks monitorCount on a short timer,
retrying up to 3 times over ~7 seconds total, then gives up (leaving
things exactly as they behave today, i.e. no regression for genuinely
absent monitors). On success it calls the same
AppletManager.loadAppletsOnPanel / layout-refresh calls the main restore
path already uses, so restored panels behave identically either way.

Testing

Reproduced on a laptop with a native HDMI port + a USB-C->HDMI adapter
driving a third external monitor. Before the patch: unplugging and
replugging the USB-C-adapter monitor reliably drops its panel, requiring
a manual "Add panel" to bring back the saved applet layout. After the
patch: the panel reliably reappears on its own within a few seconds of
reconnecting, with no manual step needed.

Risk

Purely additive - the existing single-shot restore path is unchanged.
Worst case for an unrelated regression: a panel that's genuinely supposed
to stay hidden (its monitor truly gone) gets a few harmless extra checks
over ~7 seconds before the retry loop gives up on its own; each check is
a no-op if the monitor still isn't present.

Fixes #12467