Fix iOS word selection for CJK text

[Kyle (Kyle-Ye)]

On iOS, double-tapping 文 in 我在学习中文 can select only 文, whereas UIKit
selects 中文. This PR aligns double-tap word selection in legacy and state-based
TextFields with iOS linguistic word boundaries using NLTokenizer.

When the tokenizer returns no word, selection falls back to the existing layout
word boundary, including for whitespace. Word-selection behavior on other
platforms remains unchanged.

TextLayoutResult.getWordBoundary() remains unchanged: replacing its boundaries
would also affect other selection, word-navigation, and deletion behavior. The
platform adjustment is applied specifically to iOS TextField repeated-tap selection.

Fixes CMP-10706.

This contribution was developed with AI assistance. The implementation, tests,
and behavior were reviewed, corrected, and validated by the author.

Testing

Local validation before submission:

• Five iOS tokenizer tests passed, covering Chinese and Japanese words, UTF-16
  offsets after an emoji, Latin words, and no-word results for whitespace.
• Three native UIKit / NLTokenizer comparison tests passed.
• A standalone UI regression test passed on an iPhone 14 simulator running
  iOS 26.0: double-tapping 文 in 我在学习中文 selects 中文.

Release Notes

Fixes - iOS

• Fixed double-tap word selection for CJK text in TextFields to use native iOS
  linguistic word boundaries.

[Vladimir Mazunin (mazunin-v-jb)]

Hi!
Please, follow the CONTRIBUTING.md for the Compose Multiplatform

Actually:

• the PR description should follow the PR template
• No changes should be done in the commonMain source set. The PR needs to be rewritten without them or submit them to the AOSP first

[Kyle (Kyle-Ye)]

Hi! Please, follow the CONTRIBUTING.md for the Compose Multiplatform

Actually:

• the PR description should follow the PR template
• No changes should be done in the commonMain source set. The PR needs to be rewritten without them or submit them to the AOSP first

Vladimir Mazunin (@mazunin-v-jb) Thanks for pointing this out.

1. Updated the PR description following PULL_REQUEST_TEMPLATE.
2. The current commonMain diff only changes BoundaryFunction and adjustToBoundaries from private to internal with their implementations are unchanged. This was intended to reuse the existing boundary-to-selection logic for the iOS tokenizer.
   Does private -> internal access level changes also counted as a change? They are only meaningful with the corresponding iOS change. So submit them to AOSP is not meaningful. If the rule indeed does not allow ANY change, I'll try rewrite my PR.

[Vladimir Mazunin (mazunin-v-jb)]

Updated the PR description following

Thanks!

Does private -> internal access level changes also counted as a change?
If the rule indeed does not allow ANY change

Yes, since it is a fork of an AOSP, no changes in commonMain are allowed at all, even the smallest diffs.

So submit them to AOSP is not meaningful

In case if rewriting won't work, this is a way. It should be enough to mention in the CL description that it is required for the multiplatform support.

[Kyle (Kyle-Ye)]

Thanks for clarifying. I've removed all commonMain changes, including the visibility changes. The boundary-to-selection adapter now lives in iosMain and reuses the existing internal anchor APIs.