Bug @ UITarget.Modal

# Modal Cursor: native UI transition issue (Rising World API 0.9.3)

## Summary

`UITarget.Modal` correctly shows and manages the cursor when a custom overlay is
opened directly from the plugin radial menu. The same overlay is visible but has
no cursor when it is opened as the follow-up to a native NPC interaction or to
`Player.showItemSelectionMenu(...)`.

Pressing Escape in a broken path closes the custom overlay and keeps the cursor
hidden. Earlier tests appeared to show the cursor after Escape, but that was
caused by temporary plugin-side `setMouseCursorVisible(true)` calls scheduled
after the native UI transition. Those experiments have been removed.

The problem is independent of Shop-specific rendering: it is reproducible for
both Shop and Marketplace NPC overlays and for the Shop item-selection return
path.

## Environment

- Rising World Plugin API: `0.9.3`
- Development server
- Custom overlays are attached with `player.addUIElement(overlay, UITarget.Modal)`
- The overlay root is `BasePluginOverlayWithTabs` / `BasePluginOverlay`

## Cursor-manager status

`CursorManager` is not involved in the current paths:

- no active `CursorManager.show(...)` or `showModal(...)` call remains;
- `BasePluginOverlay.close()` no longer invokes `CursorManager.hide(...)` or
  `forgetModal(...)`;
- the temporary direct `setMouseCursorVisible(true)` experiments were removed,
  because they did not make the cursor visible and could re-show it after
  Escape.

The current behavior contains no plugin-side cursor command: the native modal
Escape path closes the overlay and leaves the cursor hidden.

## Shop reference paths

### Working: direct Shop entry from the plugin menu

Source: `rw-plugin-oz-shop/src/de/omegazirkel/risingworld/shop/PluginGUI.java`

1. The player chooses Shop in the plugin radial menu.
2. `PluginGUI.openDirectShop(player)` hides the radial menu.
3. It calls `plugin.openShopUI(player)` directly.
4. `ShopRuntime.openShopUI(player)` calls `openShopOverlay(player, null)`.
5. `ShopRuntime.openShopOverlay(...)` creates `ShopOverlay` and attaches it via
   `player.addUIElement(overlay, UITarget.Modal)`.

Result: overlay and cursor are both visible; Escape closes the overlay and
hides the cursor correctly.

### Failing: Shop trader NPC interaction

Source: `rw-plugin-oz-shop/src/de/omegazirkel/risingworld/ShopRuntime.java`

1. The player uses the default interaction on a registered trader NPC.
2. `onPlayerNpcInteractionEvent(...)` resolves the `Trader` and captures the
   `Player` before the event can expire.
3. It closes built-in UI windows and calls `openTraderUI(player, trader)`.
4. This creates the same `ShopOverlay` and attaches it to `UITarget.Modal`.
5. `event.setCancelled(true)` is invoked at the end of the handler.

Result: overlay is visible, cursor is missing. Pressing Escape closes the
overlay and keeps the cursor hidden.

### Failing: return from the native item-selection menu

Source: `rw-plugin-oz-shop/src/de/omegazirkel/risingworld/shop/ui/ShopOverlay.java`

1. An admin presses **Add offer** in the Shop overlay.
2. `selectOfferToAdd()` calls
   `player.showItemSelectionMenu(true, true, true, false, callback)`.
3. The native selector closes/hides the custom modal.
4. The callback stores the selected offer, removes the old Shop overlay
   server-side, and opens a fresh Shop modal with `openShopUI(...)` or
   `openTraderUI(...)`.

Result: the fresh Shop overlay is visible but has no cursor. Escape closes the
overlay and keeps the cursor hidden.

## Attempts already ruled out

- Opening the modal immediately versus after short delays.
- Capturing `Player` before scheduling work, avoiding access to an expired
  `PlayerNpcInteractionEvent`.
- Moving `event.setCancelled(true)` to the end of the NPC handler.
- Explicit `player.setMouseCursorVisible(true)` immediately and after 100 ms /
  500 ms: did not activate the cursor during the overlay and incorrectly
  re-showed it after Escape. These temporary calls were removed.
- Removing old modal roots server-side before opening the replacement overlay.
- Removing all active `CursorManager` use from the overlay close path.

## Working hypothesis

The client retains an internal native UI/input ownership state after an NPC
interaction or item-selector callback. It permits the custom `UITarget.Modal`
to render but does not hand it mouse/cursor ownership. Escape closes the modal,
but does not grant cursor ownership afterwards.

The direct radial-menu path does not pass through that state and works.

## Desired API behavior / question

What Plugin API call or event ordering is required to transfer mouse input to a
new `UITarget.Modal` after either:

1. `PlayerNpcInteractionEvent` (with the interaction cancelled), or
2. `Player.showItemSelectionMenu(...)` callback?

Ideally, attaching a modal from either follow-up path should have the same
cursor and Escape behavior as attaching it directly from a plugin radial menu.