1. Action System
     tui-pages intentionally does not provide ActionResolution like client/src/action_engine/action_decider/
     handler.rs:23. Replace it in the client adapter/handler, not in tui-pages.

     Best path: keep the routing logic as app code inside TuiActionHandler::handle_action, or keep a private helper
     equivalent to ActionDecider::resolve. ctx.current_view and ctx.focus from tui-pages/src/runtime/mod.rs:181 give
     you enough data to route page/canvas/global actions. This is a client philosophy change: routing becomes part of
     the app handler, while tui-pages only provides focus/view/input context.
  2. Overlay Types
     No tui-pages change needed. Your old OverlayKind maps naturally to the generic O parameter.

     Define something like client-side enum ClientOverlay { CommandBar, SearchPalette, FindFilePalette, Sidebar,
     Picker }, then use FocusTarget::Overlay(ClientOverlay::CommandBar) etc. DialogButton(usize) should probably
     become FocusTarget::ModalItem(usize) if you use the modal path, because tui-pages separates simple named overlays
     from modal item focus in tui-pages/src/focus/target.rs:19.
  3. String vs Type-Based Modes
     This is not a real incompatibility. ModeId is just a typed wrapper over strings and implements AsRef<str>/
     From<String> in tui-pages/src/runtime/mod.rs:13. Your current KeyMode::as_str() values already match the tui-
     pages::modes constants.

     The actual migration is moving mode calculation from FocusTarget::mode_hint() in client/src/focus_manager/
     target.rs:50 into PageSpec::modes(...). Since page_spec(view, state, focus) receives focus, you can preserve the
     same behavior there. Watch one behavior: the old client converts plain insert-mode chars into
     CanvasAction::InsertChar in client/src/input_pipeline/pipeline.rs:90; tui-pages returns PipelineResponse::Type
     instead. Preserve that in TuiActionHandler::handle_text.
  4. Page Identification
     PageIdentifier should likely disappear. It duplicates AppView. tui-pages already gives ctx.current_view, so
     checks like PageIdentifier::Form(_) become matches!(ctx.current_view, AppView::Form(_)).

     This is a natural cleanup, not a tui-pages gap. The only case to keep a separate identifier is if you
     intentionally want to collapse several AppView variants into one routing bucket. Even then, make it a client-
     local helper derived from AppView, not a runtime concept.