[adm 8] Build first-class `/ankh/screens` and navigation configuration

[artiphishle]

Roadmap: #115

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

Previous roadmap step

[adm 7] (#122) restores in-canvas structural editing with one canonical placement model. This issue adds global screen/route/navigation administration without duplicating component-tree manipulation in a separate Layers panel.

Goal

Build a first-class Screens administration area for managing app screens/routes and navigation configuration.

Target direction:

/ankh/screens
/ankh/screens/{stable-screen-key}

The exact stable identifier and route shape must be decided after inspecting current screen/route contracts. Do not freeze screen names into URLs if a more stable canonical ID exists.

Requirements

Screens overview

Provide a production-quality overview using appropriate ZORA table/list primitives.

Support, where semantically valid:

• view all screens/routes;
• create a screen;
• delete a screen with safe validation;
• reorder screen position where ordering is meaningful;
• configure whether a screen appears in primary navigation;
• distinguish navigable-but-hidden routes from primary-nav entries;
• identify active/initial route;
• enter screen-specific administration.

Navigation configuration

Keep navigation configuration coherent with Screens.

Support current canonical navigator concepts such as stack/tabs/drawer according to contracts/runtime support.

Do not create a separate /ankh/navigation section unless investigation proves Screens cannot cleanly own the global navigator/initial-route concerns.

Screen-specific route

/ankh/screens/{...} should provide a future-proof location for screen-specific administration without forcing unrelated global features into the overview.

This issue should implement only current screen/navigation concerns; analytics/SEO/etc. may link here later but are out of scope now.

No Layers panel

Do not restore the historical mixed LayersPanel.

Component ordering/structure manipulation belongs to [adm 7]. Reuse the same underlying helpers if a future hierarchy UI is added later.

Likely files

Non-exhaustive:

src/studioAdminRouteModel.ts
src/ui/admin/AnkhAdminShell.tsx
src/ui/admin/pages/*
src/manifestState.ts
src/core/StudioProvider.ts
src/studioSelectionModel.ts
src/host/layout/*

Historical reference: late LayersPanel, PR #82/#104 and screen-management behavior in ankhorage4; redesign as first-class routes rather than restoring the panel.

Phases

Phase 1 — screen/navigation model

Audit canonical screen/route/navigator contracts and create package-neutral view/mutation helpers where missing.

Phase 2 — /ankh/screens overview

Build create/delete/order/nav-visibility/initial-route administration.

Phase 3 — screen-specific route and hardening

Add canonical screen detail routing and ensure deep-link/refresh/admin navigation behavior.

Tests

Cover at minimum:

• screen list resolution;
• create/delete protections;
• initial-route validity;
• navigator-type mutation;
• visible-in-primary-navigation state;
• reorder semantics where applicable;
• stable screen-detail route resolution;
• hidden navigable routes remain valid;
• no duplicate Layers/placement mutation path.

Acceptance criteria

1. /ankh/screens is a first-class admin section.
2. Screens/routes can be viewed and created/deleted safely.
3. Primary-navigation visibility is distinct from route existence.
4. Navigator type and initial route are configurable where canonically owned.
5. Relevant ordering can be changed deterministically.
6. Screen-specific administration has a stable canonical route.
7. No separate /ankh/navigation is added unless implementation investigation proves it necessary and documents why.
8. No Layers panel is restored.
9. In-canvas structural editing remains owned by [adm 7] helpers.
10. Behavior-focused tests and full validation pass.
11. No legacy/compatibility/ankhorage4 dependency is introduced.