fix(ios): conflicting styles in typing attributes not correctly detected

[hejsztynx]

Summary

There was a bug which you can see in the attached video below. The issue was that when applying codeblock style, we apply it to a whole paragraph, and during this process we look for conflicting styles in the paragraph's range. The problem is, we don't look at current typing attributes for conflicting styles, as there is a case when:

• there is no conflicting style in the given paragraph range
• there is a conflicting style in typing attributes

The implemented fix is minimal, as I didn't want to tamper with current logic - that's why we catch that specific case with an if.

I've run the e2e tests, everything passes.

Test Plan

Reproduce the bug from the attached video, play around with toggling different styles.

Screenshots / Videos

Before:

Screen.Recording.2026-08-13.at.10.29.46.mov

After:

Screen.Recording.2026-08-13.at.13.47.20.mov

Compatibility

OS	Implemented
iOS	✅
Android	❌
Web	❌

Checklist

• E2E tests are passing
• Required E2E tests have been added (if applicable)

[Copilot]

Pull request overview

Fixes an iOS editor edge case where paragraph-style conflict detection missed conflicts that exist only in UITextView.typingAttributes (e.g., when applying codeblock to a whole paragraph while the conflicting style is only present at the caret).

Changes:

• Updates conflict/block detection to optionally fall back to detect: at the caret when the caret is inside the target range and any: finds no conflicts.
• Refactors the style-presence check into a single present boolean to reduce branching.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.