power@cinnamon.org: avoid re-adding contentSection in _updateProfile

[RainbowXie]

Description

Fixes #13998
Related to #12916

In files/usr/share/cinnamon/applets/power@cinnamon.org/applet.js, _updateProfile() was repeatedly calling this.menu.addMenuItem(this.contentSection) on every property change from org.freedesktop.UPower.PowerProfiles.

Because this.contentSection was already added to this.menu.box, repeatedly adding it:

1. Emitted continuous Clutter warnings in ~/.xsession-errors:
   Attempting to add actor of type 'StBoxLayout' to a container of type 'StBoxLayout', but the actor has already a parent of type 'StBoxLayout'.
2. Caused this.length in PopupMenuBase to drift on every property change.
3. Invalidated the panel container and queued full-stage redraws, which caused high GPU utilization and severe frame drops on multi-monitor / high-resolution setups.

Solution

1. Add this.contentSection to this.menu once during constructor initialization (consistent with user@cinnamon.org and removable-drives@cinnamon.org).
2. In _updateProfile(), guard addMenuItem(this.contentSection) with if (!this.contentSection.actor.get_parent()) to prevent redundant parenting attempts while preserving the ability to refresh the items within the section via removeAll() and addMenuItem(item).

Verification

Reproduction & Fix verification via DBus:

Before fix, calling _updateProfile() logged a Clutter-WARNING each time:

gdbus call --session --dest org.Cinnamon --object-path /org/Cinnamon --method org.Cinnamon.Eval '
(() => {
    let defs = imports.ui.main.AppletManager.getDefinitions();
    let power = defs.find(d => d.uuid === "power@cinnamon.org").applet;
    for (let i = 0; i < 5; i++) power._updateProfile();
    return "done";
})()
'

• Before: 5 calls generated 5 Clutter-WARNING entries in ~/.xsession-errors.
• After: 5 calls generated 0 warnings.
• Long-term soak: Verified locally via ~/.local/share/cinnamon/applets/power@cinnamon.org/ for 3+ days in a desktop session with dynamic power profile switches. ~/.xsession-errors logged 0 warnings (compared to over 3,000 instances prior to the fix), and compositor GPU usage dropped back to normal idle levels.