Fix race: guard this.playerProxy against becoming null during awaits in PanelButton

[RobRobM]

Summary

Fixes a TypeError: can't access property "metadata", this.playerProxy is null crash in PanelButton.addMenuImage() (and the same race shape in addMenuSlider()) that fires during rapid track/player transitions (e.g. browser-MPRIS players switching tracks on Radio Paradise).

Stack trace shape:

TypeError: can't access property "metadata", this.playerProxy is null
  PanelButton.js:488 — addMenuImage → updateWidgets → safeCallback → callOnChangedListeners → initPlayer

Root cause

PanelButton.addMenuImage() and addMenuSlider() both read this.playerProxy.metadata / this.playerProxy.rate after an await. During that suspension, setActivePlayer() can swap this.playerProxy to another player, or a NameOwnerChanged can drop the current one — so by the time the coroutine resumes, this.playerProxy is null and property access throws.

Fix

• Add a small #isValidProxy() helper on PanelButton that checks the proxy is still non-null and not flagged isInvalid.
• Gate the post-await code in addMenuImage() and addMenuSlider() on that helper; return early if the proxy has been swapped/dropped.

No behavior change on the happy path — guards only trigger when the proxy has already been replaced by the time the await resumes, in which case further UI work on the stale proxy would be pointless anyway.

Test plan

• Installed on GNOME Shell 49 / Wayland.
• Triggered track transitions on a browser-MPRIS source known to rapidly re-emit metadata (Brave + Radio Paradise).
• Before: repeated playerProxy is null entries in journalctl --user.
• After: no such entries over repeated transitions; panel continues to update without crashing.

Notes

This addresses a crash only. It does not change player selection logic; the "player vanishes from the panel on track change" behavior some browser-MPRIS sources exhibit has a separate root cause (transient empty xesam:title marking the player invalid) which I intend to address in a follow-up PR.

May be related to the log-spam reports in #196.