feat: complete menu editor with nested items (sub-menus) via drag-and-drop

[gabrielepiccinnu]

What

Complete the menu editor admin UI to support nested menu items (one level deep),
enabling sub-menus in themes (e.g. Bootstrap 5 dropdowns, mega menus, etc.).

Why

The backend already fully supports this:

• _emdash_menu_items has a parent_id column
• buildMenuTree() in packages/core/src/menus/index.ts already builds the hierarchy
• reorderMenuItems API already accepts parentId per item
• MenuItem type already exposes children: MenuItem[]

The admin component (MenuEditor.tsx) itself has a comment:

"simplified version without drag-and-drop"

This PR completes what was already planned and partially implemented.

Implementation

• Drag vertically → reorder (same @dnd-kit pattern as Widgets.tsx)
• Drag right > 50px → nest under the item above (DragOverlay shows live "sub-item" preview)
• Drag left > 50px → promote back to top level
• ← → buttons → keyboard-accessible depth change
• Max 1 level enforced in UI (prevents grandchildren, consistent with standard navbar patterns)
• fixOrphans() ensures structural validity after any drag operation
• Full TypeScript strict compliance

No new dependencies — @dnd-kit/core, @dnd-kit/sortable are already in packages/admin/package.json.

Who

@gabrielepiccinnu — built this while developing a Bootstrap 5 starter theme for EmDash.
The feature was needed for Bootstrap dropdown navigation and proved the backend was already ready.

I have the code ready with all checks passing (typecheck, lint:json, format).
Happy to open a PR as soon as there's alignment on this approach.

[schiste]

I’d like to include the plugin admin surface explicitly in this proposal, to make sure everything is covered.

From the current implementation, plugin routing is already capable of supporting nested plugin pages. The admin router handles plugin paths through a catch-all route, with URLs like:

• /plugins//
• /plugins//facts
• /plugins//customers
• /plugins//settings

The constraint is not routing. The constraint is that the plugin admin contract and sidebar model are still flat:

1. plugins declare adminPages
2. adminPages is currently just a flat list of route descriptors
3. the admin shell turns those into flat sidebar items
4. there is no way to express “this is the plugin root” vs “these are child pages”
5. there is no way to keep route declaration separate from navigation presentation

That becomes limiting as soon as a plugin is more than a single page. In our case, a plugin wants at least:

• overview
• repository/content list
• usage
• settings
• logs/history

Today those are all just separate flat entries, which makes the sidebar noisy and loses plugin-level IA. I think the right evolution is to model plugin admin as two separate concerns:

1. admin.pages : Route declarations. What pages exist and how they are mounted.
2. admin.nav : Navigation presentation. How those pages should appear in the sidebar.

Backward compatibility can stay simple:

• if admin.nav is omitted, derive nav from the existing flat admin.pages
• existing plugins continue to work unchanged
• new plugins can opt into grouped navigation

I would keep the rendered UI to 2 levels max to avoid insane nesting and edge cases.

That would solve the real use case without committing the admin UI to arbitrary deep trees on day one.