Split out of #282959, which is now the ~10 purely mechanical `useLayoutEffect` → `useOnChange` sites. `useNavigation` is the one that is not mechanical, so it gets its own PR. The two touch no files in common.

### Why this one is different

Everywhere else in the migration the dependency list is nothing but refs, which makes the swap timing-neutral: a ref signal is written during the DOM patch, so the effect's microtask fires straight after it with the patched DOM already in place, where the shim's `onPatched` ran it.

`useNavigation` is the only hook in the series that hands state back to the caller for a lifecycle hook to read:

```
time (down)           useLayoutEffect         useOnChange
--------------------  ----------------------  --------------------
patch DOM             -                       effect queued
onMounted (hook)      update() -> items       not registered
onMounted (consumer)  reads items[0]: ok      reads items[0]: []
microtask             -                       update() -> items
```

`onMounted` never runs again, so the missed `setActive()` is lost rather than merely delayed. This is what broke the 7 `navigation_hook` tests on the first attempt.

### What this does instead

The first version of this fixed the ordering by calling `navigator.update()` from an extra `onMounted` inside the hook. @seb-odoo's review comment on #282959 was that the actual problem is that `Navigator` is not reactive, and that is right: `items` was a plain field reassigned by `update()`, sitting outside the reactive graph, so *something* had to push a refresh in at the right moment.

So `items` is derived instead, and the ordering question disappears rather than being answered:

- `_elements` — a computed over `options.getItems()`, memoised on a shallow comparison. Every signal that callback reads (the container ref, an `isOpen()` state) is tracked, so the list re-derives on its own.
- `_items` — a computed over it that reconciles `NavigationItem`s, reusing the instance of an element that is still there so its listeners survive.
- `items` — a getter over that. Reading it from anywhere, including a consumer's own `onMounted`, derives against the DOM as it is at that moment.
- `update()` — now just an invalidation, for the DOM, which is the one input that cannot notify us. It still syncs eagerly, so `update(); this.items` keeps working for `dropdown.js`.
- `_syncActiveItem()` — the active-item reconciliation, `onUpdated` and `shouldFocusFirstItem` move out of the derivation, because they move focus and a plain read of `items` must not do that. Idempotent per derivation, which is what the hand-rolled `didUpdate` flag bought.

### Blast radius

`navigation.js` only, plus one test. No consumer changes: `items`, `update()` and `onUpdated` keep their signatures, and enterprise never constructs a `Navigator` nor calls `update()`.

Nothing reads `items` during a render — every read across both repos is a hotkey callback or an event handler. That matters now that `NavigationItem` construction, which attaches listeners and writes `ariaSelected`, happens inside a computed. It is a constraint the code satisfies today rather than one it enforces.

The destroy test stepped on `update()`, which no longer runs on mount at all, so it steps on `_syncActiveItem` instead.

### For review

- `onUpdated` and `shouldFocusFirstItem` now fire from an effect (a microtask after patch) for signal-driven changes, where `useLayoutEffect` fired them inside `onPatched`. Explicit `update()` callers are unaffected. This is the same class of timing shift that broke the tests the first time, so it is the thing to look at hardest.
- `activeItem` / `activeItemIndex` are still plain fields. Making those reactive is the other half of "properly reactive" and is deliberately not in here.

Draft until CI has had a go at it.

pos*: point_of_sale, pos_loyalty, pos_hr, pos_online_payment, pos_stock,
l10n_in_pos, l10n_id_pos

Refactor the customer display communication to make it more efficient,
decouple the terminal and display sides, and avoid unnecessary requests
when no display is connected.

- Replace the effect on `pos_service` with targeted listeners on order-related events.
- Split `customerDisplayService` into two OWL plugins: `CustomerDisplayTerminalPlugin` for the PoS terminal and `CustomerDisplayPlugin` for the customer display.
- Centralize payload generation through `GeneratePrinterData` and remove the deprecated `CustomerDisplayPosAdapter`.
- Replace `device_uuid` with a `device_identifier` generated by `DeviceIdentifierSequence`.
- Use a registration route to track connected customer displays: displays announce themselves with `ADD` and `REMOVE`, while terminals use `PING` to discover displays after startup or reload.
- Skip payload generation and requests when no customer display is connected.
- Refactor customer display tests to exercise the real application flow and assert against system-generated payloads.

```mermaid
flowchart LR
    POS([PosStore])
    UI([Customer display UI])

    subgraph Terminal["CustomerDisplayTerminalPlugin — app/plugins"]
        direction TB
        initT["init({ identifier, models, scale, bus, ... })"]
        sendOrder["sendOrder(order)"]
        build["_buildDisplayPayload()"]
        send["send(payload)"]

        sendOrder --> build --> send
    end

    subgraph DisplaySide["CustomerDisplayPlugin — customer_display"]
        direction TB
        initD["init({ bus })"]
        onData["_onDataReceived()"]
        data[("data — signal")]

        onData --> data
    end

    POS -->|initCustomerDisplay| initT
    POS -->|order or screen changed| sendOrder
    UI -->|mounted| initD

    send -->|"update_customer_display — bus"| onData
    send -.->|"BroadcastChannel — only if the request fails"| onData
    data -->|render| UI
```

Task-5911881