[adm 7] Restore production-quality Insert and placement-backed in-canvas DnD

[artiphishle]

Roadmap: #115

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

Previous roadmap step

[adm 6] (#121) restores selected-node binding authoring. This issue extends the same selection-aware AppBar and canonical placement model with production-quality Insert/Delete and in-canvas drag-and-drop.

Repository impact

Likely:

• ankhorage/studio
• ankhorage/zora only if metadata/slot capabilities are incomplete
• ankhorage/react-native-reanimated-dnd-web only if the DnD implementation boundary lacks required reusable behavior

Do not add Studio-local workarounds for missing owning-package capabilities.

Goal

Restore intuitive component insertion and real placement-backed drag-and-drop directly in the app editing surface.

Requirements

Canonical placement model

Use one placement model for all insert/move behavior.

Support, where valid:

• before;
• inside;
• after.

Validate using canonical injected/ZORA metadata such as allowedChildren and slots. Root/invalid placements must remain protected.

Contextual Insert

Use the selected-node AppBar architecture from [adm 1].

Expose contextual actions such as Add child, Add item, Add image or equivalent only when component capabilities justify them. Do not hardcode one universal wording/action for every component.

Do not restore a permanent legacy Toolbox panel.

DnD UX

The old behavior was functionally promising but not production-quality. Improve it materially:

• drag handle/grab target must be comfortably usable, not a tiny hit area;
• dragged content should have a meaningful visible preview approximating its real size/shape;
• prospective drop location should visibly make space so the user can understand the final placement;
• drop zones/states must clearly distinguish before/inside/after;
• invalid placements must communicate rejection rather than silently failing;
• touch and pointer input must both be considered;
• DnD chrome must not corrupt persisted manifest/layout.

Do not implement a second tree or placement algorithm for a future Layers UI. Reusable functions should make such a future surface possible later.

Delete

Restore contextual delete for selected nodes with appropriate protection/confirmation where destructive ambiguity exists. Root/non-deletable nodes must be protected by canonical rules.

Likely files

Studio, non-exhaustive:

src/insertModalModel.ts
src/studioSelectionModel.ts
src/manifestState.ts
src/ui/useStudioAppBarAugmentation.ts
src/ui/AnkhStudio.ts
src/ui/canvas/*
src/dnd/*
docs/studio-canvas-drag-model.md

Historical references include ankhorage4 PR #253/#254 and late placement/tree DnD behavior. Reference only; redesign the UX.

Phases

Phase 1 — placement/insert model hardening

Unify insert/move validation around one canonical placement model and metadata injection.

Phase 2 — contextual Insert/Delete

Add real selected-node AppBar contributions and insertion flow with blueprint/default props.

Phase 3 — production DnD UX

Implement usable handles, previews, displacement/drop feedback and valid placement execution.

Tests

Cover at minimum:

• before/inside/after placement calculations;
• allowedChildren/slot validation;
• invalid/root moves;
• same-parent and cross-parent moves;
• insertion blueprint/default props;
• contextual action availability;
• delete protections;
• deterministic manifest mutation after move/insert/delete;
• drag-state helpers and drop-target resolution through unit-testable models.

Do not introduce a new cross-repo E2E strategy; create [Proposal] ... separately if needed.

Acceptance criteria

1. Insert and move use one canonical placement model.
2. Valid before/inside/after placements work.
3. ZORA metadata/slots govern valid children.
4. Contextual Insert/Add actions appear only when meaningful.
5. No permanent Toolbox panel is restored.
6. Drag handles are comfortably usable.
7. Drag preview and prospective drop placement are visually understandable.
8. Invalid placements are clearly rejected.
9. Delete is contextual and safely validated.
10. Root/non-deletable rules are protected.
11. No separate Layers panel/tree implementation is added.
12. Behavior-focused tests and full validation pass.
13. No legacy/compatibility/ankhorage4 dependency is introduced.