Rebuild UI as a scriptable element tree, archive the old system

The old UI system (X-macro static element list, hand-authored C
screens/widgets/focus stack) is archived under archive/ rather than
deleted, since it's a useful reference during the rewrite.

New native UI element pool (src/dusk/ui): a flat UI_ELEMENTS[128] pool
of tagged-union elements (Label, Rectangle, Scripted), a real
persistent parent/child tree (children[8] per element, cycle- and
capacity-checked uiElementSetParent), always-fresh worldX/worldY
(cheap enough to recompute on every read, no dirty-flag cache needed),
and cascading dispose. Rendering stays manual/immediate: a scripted
element with no render() override auto-renders its children by
default, but overriding render() takes full control (an override must
call renderChildren() itself to opt back in) -- this is deliberately
preserved end to end via a render()-shadow trampoline so overriding
render() always keeps working the same way regardless of how a node
is reached.

New scripting layer (src/dusk/script/module/ui): UIElement/Label/
Rectangle JS classes (Label/Rectangle share UIElement's prototype via
manual chaining, not JS `extends`), exposing x/y/worldX/worldY/parent/
add()/remove()/render()/renderChildren()/dispose(). UI.add()/
UI.remove() manage top-level render roots, mutually exclusive with
being someone's child.

Also: Scene gains a lateUpdate() hook (called once per frame after
every other update, for things like camera-follow that need to react
to where everything else ended up); several duskrpg call sites
(cutscene items, entityinteractable, entityplayer) that depended on
the now-archived RPG textbox are stubbed to console output instead of
a dialogue box, pending the new UI reaching that far.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

types/scene/scene.d.ts

@@ -31,8 +31,10 @@ declare class Scene {
    * Scene.set() call installed (calling its dispose(), then destroying
    * the scene it owned), then creates and activates a fresh Scene and
    * calls the new module's init() with it active -- so init() can use
-   * `new Entity()`/etc. as usual. The module's update() (if defined) is
-   * then called once per engine frame until Scene.set() is called again.
+   * `new Entity()`/etc. as usual. The module's update() and lateUpdate()
+   * (if defined) are then each called once per engine frame -- update()
+   * first, lateUpdate() after everything else has updated -- until
+   * Scene.set() is called again.
    *
    * Typical usage (see require.d.ts):
    * ```js
@@ -55,6 +57,14 @@ interface SceneModule {
   /** Called once per engine frame while this module is the active scene. */
   update?(): void;
 
+  /**
+   * Called once per engine frame, after every other update (entities,
+   * physics, UI, etc.) has already run for that frame -- useful for
+   * things like camera follow that need to react to where everything
+   * else ended up this frame, rather than where it was at the start.
+   */
+  lateUpdate?(): void;
+
   /** Called once when this module is replaced by another Scene.set() call. */
   dispose?(): void;
 }