Extend per-feature config to code / tables / highlight / marks #1097

Summary

#754 is adding a configurable headings option (closing #614), and Lexxy.configure already exposes capability switches like attachments: false, markdown: false, richText: false. I'd like to extend that same per-key, default-preserving pattern to a few more features so apps can tailor the editor without forking:

• code — disable code blocks and inline code.
• tables — disable table insertion.
• highlight — disable the color-highlight feature.
• marks — choose which inline marks are available (bold / italic / strikethrough / underline).

Heading levels are already covered by #754 — not re-proposing them here, I'd just build on that.

Each option defaults to today's behavior; nothing changes unless an app opts in.

Motivation

Same need as #614/#754, generalized: CSS-hiding a toolbar button doesn't disable a feature — markdown shortcuts, keyboard shortcuts, and paste/import re-introduce it. True disabling needs editor-level handling (node registration, command interception, transformer filtering, import sanitization). We're carrying these as fork patches and would rather upstream them. (@lylo's point on #754 about restricting what customers can insert is the same underlying need.)

Proposed shape

Mirrors #754's headings and the existing flat keys:

Lexxy.configure({
  default: {
    code: false,
    tables: false,
    highlight: false,            // or { enabled: false } to preserve the existing buttons/permit object
    marks: ["bold", "italic"],   // allowlist; default ["bold","italic","strikethrough","underline"]
  }
})

// also per-editor, via attributes
<lexxy-editor code="false" marks='["bold","italic"]'></lexxy-editor>

code / tables are booleans exactly like markdown / attachments. marks follows the same array shape as #754's headings. highlight is the one open question — bare false vs { enabled: false }, since it already holds a buttons/permit object.

Questions

1. In scope? Following @samuelpecher's steer on feat: enable headings to be configurable #754 (config-only, keep defaults), I'd keep each of these config-only and default-preserving — no UI or behavior changes.
2. Shape preferences — especially marks (allowlist vs per-mark booleans) and highlight (bare boolean vs object)?
3. I'd open these as small, separate, test-covered PRs (Playwright + Action Text system tests), same as feat: enable headings to be configurable #754. Preferred order, or any you'd reject up front?

I already have code implemented and tested, and can open it first as a reference.

Thanks!