Community scan CSS warnings: triage (display:contents, !important, custom-element selectors)

Review the four warning locations in styles.css and the context in #228. Confirm each warning against the explanations in this issue, then record an accept-or-fix decision for every item through the companion documentation issue. Done means all four warnings have decisions and justifications recorded in AGENTS.md, with no code changes required here.

From the Obsidian community plugin scan, tracked in #228. All four CSS warnings are already understood; the action is a per-item accept-or-fix decision. Justifications get recorded in AGENTS.md by the companion documentation issue (see #228 for the split), so no code changes are expected here.

1. styles.css:65 — display: contents "only partially supported by Obsidian 1.7.4"

.supernote-toolbar-group uses display: contents so each button wraps individually within the toolbar's flex-wrap instead of the whole group wrapping as one block (added for the button-group wrapping fix in #157). The scanner's 1.7.4 baseline is below this plugin's minAppVersion (1.8.7), so every Obsidian version that can install the plugin already has the feature in its Chromium; "partially supported" reflects the long-standing display: contents quirk classification, not a real gap for us.

Options: accept + document (recommended), or restructure the toolbar-group layout to avoid display: contents (revisits #157's fix — not obviously worth it).

2. styles.css:110 — !important on .internal-embed.supernote-embed { display: flex !important; }

Single-property use, already documented in a long comment in styles.css itself: it's the narrowest robust way to beat both Obsidian core's .internal-embed:not(.image-embed) { display: block; } and Live Preview's .markdown-source-view.mod-cm6 .cm-content > * { display: block; !important; } reset (confirmed via headless-Obsidian testing during the SupernoteEmbed rewrite, #183/PR #185). The styles.css comment also explains why matching Live Preview's exact selector specificity instead is fragile against Obsidian changing its own selector.

Options: accept + document (recommended), or chase specificity.

3. styles.css:46,133,159,184 — "unknown type selector" supernote-viewer / supernote-atelier-viewer

These are the plugin's own custom elements (the web components from #183), styled as host elements in the light DOM — the selectors are correct by construction, and the CSS linter simply doesn't know about custom elements. Not fixable without renaming the elements, which would be a breaking change to the web component's public API.

Options: accept + document (only sensible option).