[adm 9] Restore production-faithful Preview mode

[artiphishle]

Roadmap: #115

Respect the roadmap first and the AGENTS.md file of every repository touched.

Previous roadmap step

[adm 8] (#123) establishes first-class screen/navigation administration. This issue restores Preview as a thin interaction-mode switch over the same real application runtime.

Current registry ownership baseline: completed issue #132. @ankhorage/zora owns ZoraProvider and the canonical concrete ZORA_COMPONENT_REGISTRY; @ankhorage/runtime is headless and owns only generic registry/runtime mechanics; Studio owns only Studio/app extension composition.

Goal

Restore a quick AppBar eye/Preview action and make Preview behave like the actual app rather than a separate fake rendering path.

Core principle

Preview is not a second application representation.

Edit mode
  -> same app/runtime
  -> Studio selection/chrome/DnD enabled
  -> normal component actions suppressed for authoring

Preview mode
  -> same app/runtime
  -> authoring interactions/chrome disabled
  -> normal component actions execute

Do not introduce a parallel preview manifest or unsaved preview-only model.

Canonical registry composition

Edit and Preview must use the same canonical registry ownership path established by #132:

ZORA_COMPONENT_REGISTRY from @ankhorage/zora
  + Studio/app extension registries
  -> composed with @ankhorage/runtime generic registry helpers
  -> injected into RuntimeRenderer

The concrete ZORA components used by Runtime must originate from the same canonical @ankhorage/zora ownership as ZoraProvider.

Studio must not provide a copied, fallback, compatibility, or re-owned base ZORA registry. Runtime must not import concrete ZORA components.

Mode switching may change authoring wrappers/configuration such as action suppression and selection chrome, but must not switch to a different base component ownership path.

Requirements

• eye/Preview action remains quickly accessible in the main AppBar;
• switching mode preserves the current app route where possible;
• Preview uses the canonical persisted/current project manifest/config architecture;
• Runtime rendering, registry composition, actions, bindings and data execution follow the same production path used by the app;
• the base concrete component registry always comes from @ankhorage/zora and is injected into headless Runtime;
• Studio/app extension registries are composed using Runtime's generic registry helpers;
• selection chrome, authoring DnD and contextual editing affordances are disabled in Preview;
• normal button/navigation/data actions execute in Preview;
• returning to Edit restores authoring behavior cleanly;
• runtime diagnostics remain available where useful without changing app behavior.

Keep architecture open to rendering real/custom navigators in edit mode later, but do not turn that future enhancement into a blocker unless it is now trivial and naturally part of the same runtime composition.

Historical reference

Use late AnkhStudio, ManifestNavigatorPreview, preview runtime config and PR #228/#419 behavior in ankhorage4 only as reference. Reuse current standalone runtime composition rather than resurrecting a separate historical preview renderer.

Likely files

Non-exhaustive:

src/ui/AnkhStudio.ts
src/ui/useStudioAppBarAugmentation.ts
src/runtime/previewRegistry.ts
src/runtime/appExtensionRegistry.ts
src/runtime/previewRuntimeConfig.ts
src/runtime/actionSuppression.ts
src/runtime/index.ts
src/core/StudioProvider.ts

Runtime package files should only change if a genuinely missing generic/headless production-runtime capability is identified. Do not reintroduce a concrete ZORA dependency into Runtime.

Phases

Phase 1 — mode model and runtime composition

Establish one explicit edit/preview interaction mode over the same runtime tree and existing canonical injected registry composition from #132.

Phase 2 — AppBar and authoring suppression

Wire the eye action, selection/chrome/DnD suppression and real action execution without changing base registry ownership.

Phase 3 — navigation/diagnostic hardening

Ensure route continuity, diagnostics and mode transitions remain deterministic.

Tests

Cover at minimum:

• edit -> preview -> edit mode transitions;
• edit mode suppresses normal actions;
• preview mode permits canonical actions;
• selected-node authoring chrome is absent in Preview;
• current route survives mode switching where valid;
• no second manifest/preview state is created;
• both modes use ZORA's canonical ZORA_COMPONENT_REGISTRY plus extension composition through Runtime helpers;
• no copied/re-owned/fallback base registry exists in Studio or Runtime;
• runtime config/registry composition remains canonical.

Acceptance criteria

1. A quick eye/Preview AppBar action exists.
2. Preview and Edit use the same real runtime/rendering composition.
3. Both modes source the concrete base registry from @ankhorage/zora and inject it into headless Runtime.
4. Studio composes only Studio/app extensions through Runtime's generic registry mechanics and does not re-own the ZORA base registry.
5. Edit mode authors/selects; Preview executes app interactions.
6. Preview has no selection/DnD/editing chrome.
7. Current app route is preserved where valid.
8. No fake/parallel preview renderer or manifest state is introduced.
9. Runtime diagnostics remain useful without diverging behavior.
10. Architecture remains open to custom navigator fidelity later.
11. No concrete ZORA dependency/registry ownership is reintroduced into Runtime.
12. Behavior-focused tests and full validation pass.
13. No legacy/compatibility/ankhorage4 dependency is introduced.