fix(manual-edit): confirm element deletion

[roian6]

Fixes #3846

Why

While rebasing the original deletion-confirmation fix onto the manual-edit work merged in #5890, I found that users could still bypass confirmation from the selection action bar or the canvas keyboard path. A destructive delete could also outlive a target, file, project, source, or viewer-lifecycle change while an asynchronous save or source verification was pending.

What users will see

Deleting a selected element—whether from the inspector trash action, the selection action bar, or Delete / Backspace on the canvas—now opens the same inline warning in the inspector. Cancel keeps the element and any unsaved inspector draft unchanged; Delete element performs the existing guarded, undoable removal.

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 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)
• Default behavior change — existing destructive deletion paths now require confirmation
• None — internal refactor, docs, tests, or translation update only

Screenshots

Bug fix verification

• Test paths that reproduce the bugs:
  • apps/web/tests/components/FileViewer.manual-edit.test.tsx
  • apps/web/tests/components/ManualEditPanel.test.tsx
  • apps/web/tests/components/ManualEditSelectionOverlay.test.tsx
• Did the tests go red on main and green on this branch? Yes. During the rebase, the focused regressions were first run against main's pre-fix deletion path and failed on direct overlay/iframe deletion, dirty-draft preservation, and stale asynchronous deletion authorization. They pass after this change, including held save/source-verification, file/project/source change, same-ID reselection, and unmount cases.

Validation

• Focused Vitest: 99 passed across the three test files above
• Web typecheck: passed
• Root typecheck: passed
• Repository guard: passed
• Web production build: passed
• Independent blocker review of the final authorization and accessibility delta: passed, no PR-introduced blockers

Implementation notes

• Inspector, selection-overlay, and iframe deletion requests converge on the existing inline confirmation UI.
• The final-root guard and removeManualEditTarget() run only after final confirmation.
• Pending deletion is disarmed synchronously on target, file, project, source-incarnation, mode, or lifecycle changes, including while a style save or persisted-source verification is pending.
• feat(manual-edit): add direct manipulation and reliable history #5890's direct-manipulation, in-place DOM update, save, undo, and history behavior remains intact.

[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).

[roian6]

Rebased onto the latest main after #5890 merged. The inspector, selection action bar, and Delete/Backspace path now converge on the existing inline confirmation flow, so no manual-edit deletion bypasses confirmation. The merged #5890 direct-manipulation/history behavior is otherwise preserved. Focused regression tests, web/root typechecks, guard, build, and final blocker review pass; the remaining full-suite failure reproduces in App.connectors.test.tsx on current main.

[lefarcen]

Hey @roian6 — thanks for rebasing this onto #5890 and tightening the shared deletion path.

The updated write-up is already much clearer. Before pool review picks this up, could you add three bits back to the PR body: a short user-facing What users will see summary, the relevant Surface area checkboxes, and the explicit bug-fix verification note that this went red on main and green here? Your existing Verification section already covers Validation as-is.

[roian6]

@lefarcen Updated the PR body with the requested template fields: a concise What users will see summary, explicit Surface area checkboxes, and the bug-fix red on main / green here verification note. I kept the existing validation results under the template's Validation heading.

[lefarcen]

Thanks @roian6 — the PR body now covers the requested template fields, so that part is in good shape.

We'll leave the remaining review and validation flow with the assigned reviewers from here.