fix(editor): preserve custom HTML by blocking lossy visual conversion

[heyramzi]

Summary

Prevent templates with unsupported custom HTML from switching into the visual editor, where the markup would be normalized into a lossy TipTap representation.

Problem

The editor already detects custom HTML and warns that visual mode cannot preserve it faithfully. But the current dialog still offers a destructive Switch Anyway path, which makes it too easy to mutate production email markup accidentally.

This is especially risky for templates that depend on:

• inline styles
• CSS classes
• custom attributes
• table-based layout
• wrapper elements that are valid for email HTML but not represented in the visual editor

What changed

• extracted mode-switch decisions into a small pure helper
• kept HTML mode authoritative for unsupported templates
• removed the destructive Switch Anyway path from the custom HTML warning dialog
• clarified dialog copy so the user understands why the template remains locked to HTML mode
• added focused tests covering initial mode detection and blocked visual-mode switching for custom HTML

Why this approach

The safe path already exists: users can continue editing in HTML mode and still preview the rendered email without converting the source into visual-editor content. Blocking the destructive transition preserves the original template instead of asking users to make an unsafe choice.

Verification

• yarn vitest run --config ./vitest.mode-guards.config.cjs apps/web/__tests__/EmailEditor/modeGuards.test.ts

Note: the repository's default Vitest setup requires a database and runs global DB initialization for all suites, so I used a minimal temporary config to verify this pure unit test in isolation.

[driaug]

The reason the destructive action is there in case there is an edge where a template gets incorrectly identified but is parseable.

This would allow the user to switch between modes, in your solution this is no longer possible. To completely lose a template you would need to press the destructive button AND save the template. You can always refresh the page to discard the changes.

[heyramzi]

Good point about false positives in the detection. I've revised the approach:

Before: Block the switch entirely when custom HTML is detected.
Now: Allow the switch, but snapshot the original HTML first. A small banner appears at the top of the visual editor with a one-click "Revert to HTML" button that restores the exact original markup.

This way:

• Users can always switch modes (your concern about incorrectly flagged templates)
• The original HTML is never lost until the user explicitly dismisses the banner or saves (my concern about accidental destruction)
• No modal dialog, no friction for the happy path
• Detection accuracy becomes less critical since the action is always reversible

The snapshot is cleared when switching back to HTML mode or when the user dismisses the banner.