[Bug]: Account submenu in the tray menu is always empty on GNOME — AboutToShow returns false after populating it, and the menu is rebuilt every ~3s

## Bug description

On GNOME/Wayland with the AppIndicator extension, clicking the account entry in the tray
context menu does nothing. The entry renders with a submenu chevron, but no submenu ever
appears. Every other entry in the menu (`Add account`, `Settings`, `Quit`) works.

Inspecting the DBusMenu directly shows the client *does* build the submenu, but reports to
the consumer that nothing changed, so the shell keeps rendering its cached — empty — copy.

There are two distinct defects, and I think the first one alone is enough to cause this:

**1. `AboutToShow` returns `false` after mutating the layout.**
The submenu is populated lazily on `AboutToShow`, but the method returns `false`, which per
the DBusMenu spec means *"this should not result in the menu being updated"*. The consumer
therefore does not re-fetch the layout and displays the stale, empty submenu.

**2. The whole menu is rebuilt and renumbered every ~3 seconds.**
`LayoutUpdated` fires ~10 times in 34 seconds and all item IDs are reassigned (the account
row went from id `12` to id `63` during a short debugging session). Any id the shell is
holding onto goes stale almost immediately, so even a consumer that did call `AboutToShow`
is likely to call it on an id that no longer exists.

## Steps to reproduce

No GNOME or AppIndicator needed — this is reproducible against the D-Bus interface directly.

```bash
# 1. Find Nextcloud's StatusNotifierItem. Look for the one whose Id is "Nextcloud";
# its Menu property is /MenuBar.
gdbus call --session -d org.kde.StatusNotifierWatcher -o /StatusNotifierWatcher \
-m org.freedesktop.DBus.Properties.Get \
org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems

BUS=:1.107 # substitute the unique name found above

# 2. Top-level layout. The account row advertises children-display=submenu, enabled=true.
gdbus call --session -d $BUS -o /MenuBar \
-m com.canonical.dbusmenu.GetLayout 0 1 "['label','children-display']"

ACCOUNT_ID=63 # substitute the account row's id from step 2

# 3. The submenu has no children.
gdbus call --session -d $BUS -o /MenuBar \
-m com.canonical.dbusmenu.GetLayout $ACCOUNT_ID 1 "['label']"

# 4. Ask the client to prepare it.
gdbus call --session -d $BUS -o /MenuBar \
-m com.canonical.dbusmenu.AboutToShow $ACCOUNT_ID

# 5. The children now exist — but step 4 said they would not.
gdbus call --session -d $BUS -o /MenuBar \
-m com.canonical.dbusmenu.GetLayout $ACCOUNT_ID 1 "['label']"
```

Output:

```
# step 3 — empty submenu, revision 1
(uint32 1, (63, @a{sv} {}, @av []))

# step 4 — "no update needed"
(false,)

# step 5 — revision jumped to 19 and 15 children appeared
'User status', 'Away', 'Local folder', 'Search', 'Apps', 'Notifications',
<3 app entries>, 'Recent activity', <4 activity entries>, 'More activity…'
```

So `AboutToShow` changed the layout and bumped the revision from 1 to 19, yet returned
`false`.

For the second defect:

```bash
timeout 34 gdbus monitor --session -d $BUS | grep -c 'com.canonical.dbusmenu.LayoutUpdated'
# → 10
```

Re-reading the root layout after that shows the account row under a different id, and its
submenu empty again.

## Expected behaviour

Clicking the account entry opens the submenu with the account's actions.

`AboutToShow` should return `true` when it has populated or modified the submenu, so the
consumer re-fetches the layout. Ideally the tray menu would also not be torn down and
renumbered every few seconds while it is idle.

## Actual behaviour

The submenu renders empty; clicking the account entry appears to do nothing. All the
account-level functionality behind it is unreachable from the tray.

## Environment

| | |
|---|---|
| Client | 34.0.1daily (Flathub, `com.nextcloud.desktopclient.nextcloud`) |
| Runtime | `org.kde.Platform/x86_64/6.10` |
| OS | Debian 13 (trixie) |
| Desktop | GNOME Shell 48.7, Wayland |
| Tray support | `gnome-shell-extension-appindicator` v64 |
| Client log | `os: "KDE Flatpak runtime" platform: "wayland"` |

The client registers its SNI under its unique bus name rather than a well-known
`org.kde.StatusNotifierItem-*` name, and logs `libayatana-appindicator is deprecated`.

## Notes

The icon and the menu itself work fine, so SNI registration and DBusMenu transport are not
the problem — this is specifically about submenu population being announced as a no-op.

There is already a desktop-environment-keyed workaround mechanism in the codebase
(`_workaroundNoAboutToShowUpdate`, set when KDE is detected and overridable by environment
variable), so this may belong there rather than being an unconditional change. I have not
traced which function builds the account submenu or what triggers the periodic rebuild, so
I have no patch to offer — happy to run further D-Bus probes on request.

## Possibly related

- #1772 — no way to access account management on GNOME
- #6206, #10431 — other GNOME tray issues
- https://help.nextcloud.com/t/linux-desktop-client-menu-issue/166057 — same symptom
reported since 2024 across Debian, Fedora Silverblue and Nobara, no diagnosis

Trace the DBusMenu implementation around _workaroundNoAboutToShowUpdate and the code that populates the account submenu. Reproduce the behavior with the supplied gdbus calls and monitor LayoutUpdated during the idle period. Done means the populated submenu is announced for refresh and the tray menu does not repeatedly become stale through unnecessary rebuilding and ID changes.

Written by the indexing model from the issue text.