fix(manual-edit): confirm element deletion

[roian6]

Fixes #3846

Why

The Manual Edit inspector currently deletes the selected element on the first click of the trash icon. That makes an easy-to-trigger destructive action immediate even though the existing translations and footer styles already describe a confirmation step.

This fixes the reported current-main path without changing the underlying undoable remove-element patch contract.

What users will see

Clicking the trash icon now replaces the normal footer actions with an inline warning plus Delete element and Cancel actions. The element is only removed after the explicit confirmation.

The pending confirmation is cancelled when the selected target changes. Keyboard focus moves to the destructive confirmation action and returns to the trash icon when cancellation keeps the same target selected.

Surface area

• UI — new page / dialog / panel / menu item / setting / empty state in apps/web or apps/desktop (including Electron menu bar)
• Keyboard shortcut — new or changed
• CLI / env var — new od subcommand or flag, new tools-dev / tools-pack / tools-pr flag, or new OD_* env var
• API / contract — new /api/* endpoint, new SSE event, or changed shape in packages/contracts
• Extension point — new entry under skills/, design-systems/, design-templates/, or craft/, or change to the skills protocol
• i18n keys — added new translation keys (see TRANSLATIONS.md for the locale workflow)
• New top-level dependency — adding any new entry to the root package.json (dependencies or devDependencies); workspace-package package.json files are out of scope. Include a paragraph on what we get vs. what bytes we ship (see CONTRIBUTING.md → Code style)
• Default behavior change — changes what existing users experience without opting in (default model, default setting, file/SQLite schema, auto-network on startup, auto-install)
• None — internal refactor, docs, tests, or translation update only

Screenshots

Bug fix verification

• Test path that reproduces the bug: apps/web/tests/components/ManualEditPanel.test.tsx
• Did the test go red on main and green on this branch? Yes. The red test observed onApplyPatch being called by the first trash-icon click; it is now called only after confirmation.
• Integration coverage: apps/web/tests/components/FileViewer.manual-edit.test.tsx now verifies that the existing “cannot remove the final rendered root” guard is reached only after the second, confirming click.

Validation

• pnpm guard — passed
• pnpm typecheck — passed across the workspace
• pnpm --filter @open-design/web build — passed
• pnpm --filter @open-design/web exec vitest run -c vitest.config.ts tests/components/ManualEditPanel.test.tsx tests/components/FileViewer.manual-edit.test.tsx --maxWorkers=1 — 40 passed
• Isolated Playwright Manual Edit scenario — 1 passed; actual 1280×720 screenshot visually checked for complete warning text, a single Delete action, a single Cancel action, and no clipping/overlap
• Independent exact-diff review — passed with no security or logic blockers
• Full Web suite — 437/438 files passed; 4,765 tests passed; 7 skipped. The only failure was the unrelated timing-sensitive App.connectors.test.tsx privacy-banner sync assertion. The same file passed in a clean origin/main worktree and also passed once in this branch in isolation; it also reproduced intermittently in isolation without touching any files in this PR.

Adjacent work

Open PR #5890 currently adds a separate direct-manipulation path (od-edit-delete-request → removeManualEditTarget) that does not exist on main and does not route through ManualEditPanel. It remains blocked with changes requested. If that PR lands, its overlay delete action should adopt the same explicit confirmation contract before merge so it does not reintroduce a bypass.

[lefarcen]

🧪 This PR has changes that need a manual QA pass before merge — please hold off self-merging for now; we'll loop QA in once it's merge-ready (and design/product have signed off, where applicable).