Fix MenuItem.AddChild not making children visible to the desktop environment

[alex-poor]

Summary

Two related bugs in MenuItem.AddChild cause newly added submenu children to never become visible to the desktop environment.

Bug 1: MenuItem.AddChild calls emitPropertiesUpdated on the parent

In menuitem.go:78, the dirty property names returned by `child.applyProps` are passed to `item.emitPropertiesUpdated`, where `item` is the parent, not the child:

```go
dirty, errs := child.applyProps(props)
errs = append(errs, item.menu.updateLayout(item))
errs = append(errs, item.emitPropertiesUpdated(dirty)) // wrong receiver
```

Inside `emitPropertiesUpdated`, this looks up child property names (`"label"`, `"enabled"`, etc.) in the parent's `props` map, where they don't exist:

```go
for change := range props {
updated = append(updated, prop{
Name: change,
Value: item.props[change], // nil for child prop names
})
}
```

The resulting D-Bus emit fails with `"runtime error: invalid memory address or nil pointer dereference"`. `Menu.AddChild` already does this correctly by calling `child.emitPropertiesUpdated(dirty)`.

Bug 2: `setChildren` mutates `children-display` without emitting it

`MenuItem.setChildren` sets `item.props["children-display"] = "submenu"` when the item gains its first child, but never marks this property as dirty or emits a `PropertiesUpdated` signal for it. As a result, the desktop environment is never told that the item has been converted into a submenu, so children added via `MenuItem.AddChild` remain invisible — even after Bug 1 is fixed.

`setChildren` now reports the names of any properties it changed, and each caller (`MenuItem.AddChild`, `Remove`, `appendChild`, `MoveBefore`) emits `PropertiesUpdated` for the affected node when needed.

Test plan

• `go build ./...` and `go vet ./...` pass
• Manually verified with the `examples/simple` example: "Edit" submenu now renders "Add" and "Remove" children correctly
• Manually verified end-to-end in trayscale: a multi-item submenu added in `Start()` is now visible in the desktop environment's tray menu (KDE Plasma 6 on Wayland)

🤖 Generated with Claude Code

[alex-poor]

Pushed a third commit that fixes a related lock-order inversion in `MenuItem.SetProps`.

`SetProps` previously locked `item.m` before `menu.m` (line 379 then line 382). Meanwhile `dbusmenu.GetLayout` (the D-Bus method the desktop environment calls to fetch the menu) takes `menu.m` first and then `RLock`s each `item.m` as it walks the tree. With concurrent `SetProps` and `GetLayout`, the two paths deadlock waiting for each other.

In practice this hadn't shown up because `Tray.update` in trayscale runs all of its `SetProps` calls in a tight burst from a single goroutine under a higher-level mutex, and the DE rarely tries to `GetLayout` during that burst. The moment a caller invokes `SetProps` from a separate goroutine while the DE is fetching the layout (which it does on every menu open and after every `LayoutUpdated` signal), the deadlock is reliable.

The fix swaps the lock order in `SetProps` to match `GetLayout` and inlines the parent lookup that used to call `getParent` (which itself `RLock`s `menu.m` and would deadlock under the new order).