feat: name the framework being debugged in the Rozenite app

[V3RON]

Description

Names the framework a Rozenite window is attached to, now that three of them are supported and nothing said which one you were looking at.

• The standalone app names it in the status footer, next to the connection badge, and in its own window title: Lynx · Pixel 8 - Rozenite. That covers both places this app runs — a browser tab shows the title directly, and the Electron shell picks it up through Electron's default page-title propagation (the title: 'Rozenite' in packages/electron-app/src/main.js is only the value before the page loads).
• React Native DevTools keeps the title it sets itself. Rozenite does not touch it — @rozenite/runtime is unchanged against main.
• @rozenite/lynx-dev now answers ReactNativeApplication.enable with the metadataUpdated event a device implementing that domain would have sent, so a Lynx target reports its own framework instead of the host having to infer one.

Related Issue

Closes #450

Context

The framework is read per target, from ReactNativeApplication.metadataUpdated — the event React Native already sends unprompted once the domain is enabled. Nothing new is invented on the wire for React Native; it was already reporting enough, and no code was reading it.

Why integrationName and not platform. platform means the device OS everywhere else in this domain — React Native sends ios/android from RCTPlatformName and its Android equivalent — and a Lynx app runs on those same two, so platform: "lynx" would be a category error. integrationName is the free-form "which integration drives this target" field; React Native's own values there are strings like iOS Bridge (RCTBridge). The reader's precedence: a known integrationName wins, then platform === "web" (what @rozenite/chrome-extension reports, and the only framework that is a platform), otherwise React Native. That default matters — a future OS must not silently cost the label.

Why the bridge has to speak here. translate-host-message.ts already answers ReactNativeApplication.enable locally and never forwards it, because Lynx has no such domain and a -32601 would fail the connection into a permanent retry loop. Having claimed to enable the domain, it now also has to speak for it — otherwise a host that enables it and waits learns nothing, forever. Every field in the synthesized event is a real value DebugRouter reported about the client (appDisplayName, deviceName, platform from client.os, appIdentifier when present); reactNativeVersion is omitted rather than faked. HostAction's reply gained an optional events[], and the socket route resolves the client per message rather than capturing it at open, since a reload mints a fresh one.

No dev-server involvement. An earlier revision of this branch also reported the server's platform in /rozenite/app/config as a pre-handshake fallback. It answered a different question — which platform the server serves, not what the target is — so it was removed; middleware.ts and app/src/config.ts are unchanged against main. The footer and title fill in once the handshake produces the event, and getTarget() keeps the last known answer so neither blinks away while reloading or reconnecting.

Note that the label never says "Web" in practice today: Rozenite for Web is debugged through React Native DevTools, which this PR leaves alone, so a web target never reaches this app. The reader handles it anyway — it costs nothing and it is what the extension already reports — and the same is true in reverse for Lynx, whose dev server serves no Fusebox frontend.

Testing

Automated, from the repository root after git fetch origin main:

• pnpm checks:affected — 102/102 tasks
• pnpm test:affected — 63/63 tasks

New tests:

• @rozenite/lynx-dev — the metadata event's exact payload, the no-bundle-id and no-client-connected paths, that Runtime.addBinding stays a bare reply, and a real-socket test over http + ws asserting the reply arrives before the event.
• @rozenite/app — the metadata reader's precedence (Lynx, web, React Native's own integration names, unreadable payloads), that the connection notifies subscribers without a status change, that the framework survives a reconnect, the title builder's fallbacks (either part missing degrades to something readable rather than a stray separator), and that the rendered app titles its window once the target reports.

Not verified on a device: no Lynx device was available in this environment, so the Lynx handshake was exercised through the fakes above rather than end to end. The Electron title path is likewise reasoned from main.js having no page-title-updated handler, not observed — worth a quick look when someone next runs the shell. With titleBarStyle: 'hidden' the title is not drawn in the window frame, so what changes there is the window's name in Mission Control, alt-tab and the taskbar rather than anything in-window.