feat(ui): Phase 2 v3.3 — cross-platform showToast + setText (macOS, v0.5.408)

[proggeramlug]

Summary

• Adds the cross-platform runtime backbone for showToast / setText so non-harmonyos backends can light them up incrementally.
• Wires the macOS implementation as the first cross-platform target — borderless NSPanel toast presenter + id → widget-handle registry calling into the existing widgets::text::set_text_str setStringValue: path.
• Pre-existing v0.5.405 perry_arkts_show_toast / perry_arkts_set_text symbols were guarded behind feature = "ohos-napi". A non-harmonyos build of a TS program calling either failed to link with Undefined symbols; this PR fills the gap without touching the harmonyos drain-queue path.

Stacks on #322.

What landed

Runtime (always compiled)

New crates/perry-runtime/src/ui_text_registry.rs provides cross-platform stubs of perry_arkts_show_toast / perry_arkts_set_text / perry_arkts_register_text_id gated behind #[cfg(not(feature = "ohos-napi"))] so harmonyos keeps the canonical drain-queue impl in arkts_callbacks.rs (no symbol collision). Each stub forwards to a per-process AtomicPtr<()> handler slot registered via three new FFIs (js_register_show_toast_handler / _set_text_handler / _text_id_handler) — same pattern as the existing js_register_stdlib_pump.

Pending-call buffering: widget construction runs at module-init time (before app_run registers handlers), so Text("Count: 0", "counter") immediately fires perry_arkts_register_text_id with no handler available. Without buffering, the id → handle map would never populate and later setText("counter", ...) calls would silently no-op. Each pre-registration call is buffered into a static Mutex<Vec<...>>; the registration FFI drains on first registration, replaying every queued call against the fresh handler.

macOS UI (real implementation)

New crates/perry-ui-macos/src/widgets/toast.rs (~280 LOC):

• Borderless NSPanel with rounded translucent dark background + centered NSTextField, anchored near the top of the active window.
• Animates alpha 0→1 over 0.25s, holds for ~2s, fades out, closes.
• Two NSTimer targets (PerryToastFadeOutTarget + PerryToastCleanupTarget) using the same define_class! pattern as the existing app::PerryTestExitTarget / PerryTimerTarget.
• Multi-toast queueing via TOAST_QUEUE: VecDeque<String> + PRESENTING: Cell<bool> — showToast("a"); showToast("b") produces sequential banners, not "b" overwriting "a".

New crates/perry-ui-macos/src/widgets/text_registry.rs (~80 LOC):

• Mutex<Option<HashMap<String, i64>>> mapping user-supplied ids to widget handles.
• register_text_id_handler populates; set_text_handler looks up + calls the existing widgets::text::set_text_str to update the NSTextField via setStringValue:.

Both registered in app::register_cross_platform_text_handlers called from the top of app_run.

Codegen change

crates/perry-codegen/src/lower_call/native.rs: new arm before PERRY_UI_TABLE dispatch detects Text(content, id). Pre-fix, the table's "args.len() == sig.args.len() + 1 ⇒ inline_style_arg" path absorbed the id as a would-be inline-style object literal, and apply_inline_style silently no-op'd because strings aren't object literals — so the id was dropped on the floor and setText("counter", ...) had nothing to look up. The new arm lowers the create call manually, then emits a perry_arkts_register_text_id(handle, id) follow-up so the platform UI crate gets the mapping. On harmonyos that follow-up is a runtime no-op (codegen-arkts emits @State text_<id> directly into the .ets — see the #[cfg(feature = "ohos-napi")] arm in ui_text_registry.rs).

Other platforms

iOS / GTK4 / Windows / Android / tvOS / visionOS / watchOS get the runtime symbols cross-platform via libperry_runtime.a — programs link cleanly but showToast / setText no-op visibly until each platform's UI crate registers its own handlers. Each is a focused follow-up issue (the macOS-side files in this PR are the template; each platform needs its own widgets/toast.rs + widgets/text_registry.rs plus a registration call from app_run).

Test plan

• cargo build --release -p perry-runtime -p perry-stdlib -p perry-ui-macos -p perry clean (1m22s incremental).
• cargo test --release -p perry-codegen-arkts 23/23 still pass (no codegen-arkts code touched).
• cargo test --release -p perry-runtime --lib 173/0 baseline.
• Smoke compile of Text(initial, id) + Button(label, () => { setText(id, ...); showToast(msg); }) on --target macos produces a 0.9 MB binary that exits 0 in PERRY_UI_TEST_MODE=1.
• Visual emulator validation (parent will run).
• Platform follow-ups: iOS / GTK4 / Windows / Android / tvOS / visionOS / watchOS each get their own showToast + setText (separate issues).