refactor: split large mobile ink implementation files into focused modules

[markm39]

Goal

Refactor the largest implementation files into focused modules so Android parity work, page activation, engine mounting, benchmarks, and tool rendering are easier to reason about and review.

Context

The Android parity work is concentrated across several large files, which makes contributor onboarding and regression review harder than it needs to be. Current high-line-count implementation files include:

• cpp/SkiaDrawingEngine.cpp (~3.1k lines)
• ios/MobileInkModule/MobileInkCanvasView.swift (~1.9k lines)
• cpp/PathRenderer.cpp (~1.6k lines)
• ios/MobileInkModule/MobileInkBridge.swift (~1.3k lines)
• android/src/main/cpp/jni_bridge.cpp (~1.1k lines)
• android/src/main/java/com/mathnotes/mobileink/MobileInkCanvasView.kt (~1.1k lines)
• src/ZoomableInkViewport.tsx (~1.0k lines)
• src/ContinuousEnginePool.tsx (~1.0k lines)
• src/NativeInkCanvas.tsx (~900 lines)
• android/src/main/java/com/mathnotes/mobileink/MobileInkModule.kt (~650 lines)

Constraints

• Keep this behavior-preserving unless a bug fix is explicitly part of the refactor PR.
• Do not introduce stubs, TODO placeholders, or partial replacement paths.
• Preserve existing public JS and native APIs unless a breaking change is documented and justified.
• Keep Android and iOS behavior aligned while splitting platform-specific code into clear ownership areas.
• Make page lifecycle, engine assignment, input handling, rendering, serialization, and benchmark code easier to find independently.

Done when

• Large files are split into cohesive modules/classes with clear responsibilities.
• Page activation and engine mounting logic can be reviewed without reading unrelated tool-rendering or serialization code.
• Benchmark-related code has an obvious home on each platform.
• Existing tests and examples continue to pass after the refactor.
• The refactor leaves the codebase easier for contributors to patch without needing broad context across every rendering layer.