First off, thank you so much for developing `glaze` and `native`! They provide remarkably lightweight, clean, and elegant solutions for Go desktop development. Combining `native/tray` with `glaze` makes building native tray-focused webview apps a absolute breeze.

Below are two minor limitations I encountered during integration, along with a minimal reproducible example.

---

## Context / Minimal Reproducible Example

```go
package main

import (
"log"
"runtime"
"sync"
"time"

"github.com/crgimenes/glaze"
"github.com/crgimenes/native/tray"
)

type Gui struct {
lock sync.Mutex
running bool
}

func (g *Gui) dispatchOpenWindow() {
g.lock.Lock()
if g.running {
g.lock.Unlock()
return
}
g.running = true
g.lock.Unlock()

go g.openWindow()
}

func (g *Gui) openWindow() {
defer func() {
g.lock.Lock()
g.running = false
g.lock.Unlock()
}()

w, err := glaze.New(true)
if err != nil {
log.Printf("glaze new error: %v", err)
return
}
defer w.Destroy()

w.SetTitle("Glaze Window")
w.SetSize(480, 320, glaze.HintNone)
w.SetHtml(`

Hello World

`)
w.Run()
}

func main() {
runtime.LockOSThread()
gui := &Gui{}

cfg := tray.Config{
Tooltip: "Native Tray Example",
Items: []tray.Item{
{
Title: "Open Window",
OnClick: func() {
gui.dispatchOpenWindow()
},
},
{Title: "Quit", OnClick: func() { tray.Stop() }},
},
}

// ⚠️ Workaround Issue #1: Using arbitrary timer delay to auto-open window after tray init
time.AfterFunc(2000*time.Millisecond, func() {
gui.dispatchOpenWindow()
})

log.Println("Starting tray...")
if err := tray.Run(cfg); err != nil {
log.Fatalf("tray run failed: %v", err)
}
}
```

---

### Tray Initialization Lifecycle Callback (Ready)
#### Problem in Example:
In the sample code above, I must rely on time.AfterFunc(2000*time.Millisecond, ...) to launch the window after tray.Run() starts.
- If delay is too short: The native loop or window handles aren't fully ready, which can cause race conditions or panics.
- If delay is too long: The user experiences a noticeable lag before the GUI window opens.
#### Request:
Provide a callback or event mechanism (e.g., executed once the native tray handle/loop is ready) so downstream logic can safely run without hardcoded time.AfterFunc delays.

### Dynamic Menu Item Updates at Runtime
#### Problem in Example:
cfg.Items can only be defined once at initialization. Once tray.Run(cfg) is called, the menu items remain static.

In real-world apps, menu states often need to change dynamically based on app status, such as:

- Updating status text (e.g., "Status: Connected" -> "Status: Disconnected").
- Toggling action items (e.g., "Pause" -> "Resume").
- Adding or removing dynamic menu items (e.g., recent file history or device list).

#### Request:
Support updating, adding, or deleting menu items dynamically while tray.Run() is active.

Start by reading the tray.Config, tray.Item, and tray.Run entry points used in the reproduction, then trace how initialization and menu items are handled while the native loop runs. Define completion as a safe ready callback and an API for updating, adding, and deleting items during tray.Run, with behavior covering the requested status and action changes.

Written by the indexing model from the issue text.