fix(ios): seed MO-active when a reader view registers

[ddfreiling]

What & why

audioEnable enables media-overlay column-break prevention with:

self.currentReaderView?.setMOActive(true)

The call is optional-chained, so when no reader view is mounted at that moment the flag is silently dropped. A view that registers afterwards starts with isMOActive == false, and its per-resource check in navigator(_:locationDidChange:):

if shouldPreventColumnBreaks { injectColumnBreakCSS() }

never fires — shouldPreventColumnBreaks is isMOActive && preferences.preventMOColumnBreaks. So highlighted text can be split across CSS columns for the rest of the session.

Android has no equivalent gap: the flag lives on the singleton ReadiumReader, not on the widget, so a widget mounting later already sees it and re-injects on page change.

Changes

• FlutterReadiumPlugin.registerAsCurrentReaderView seeds the incoming view's MO-active state from the live navigator (timebasedNavigator is FlutterMediaOverlayNavigator).
• CHANGELOG entry under Unreleased / Fixed.

Verification

• bin/format — clean.
• bin/analyze — no issues in either package.
• flutter build ios --no-codesign in flutter_readium/example — succeeded (Built build/ios/iphoneos/Runner.app), which is the gate flutter_readium/ios/CLAUDE.md requires for Swift changes.

Not verified: no runtime check of the highlighting itself. Reproducing the original symptom needs a guided-navigation or media-overlay book whose reader view mounts after audioEnable, which the current app flow does not normally produce — the deferral in the consuming app exists precisely to avoid that ordering. Android is untouched.

Context

Found while fixing Notalib/LYT4#1467. That app defers audioEnable for guided-navigation books until the reader reports ready, and the only thing that deferral buys is this ordering. With this fix the deferral becomes unnecessary and can be removed app-side.

🤖 Generated with Claude Code

[ddfreiling]

Necessary fix to get out, I take full responsibility and merge this.