fix(android): expose screen info in bridge

[GenericJam]

Summary

• add the generated MobBridge.screenInfo entrypoint expected by Mob's optional JNI binding
• derive logical dimensions, density, and system insets from Android resources
• make template lint reject generated bridges that omit or misplace the entrypoint

Verification

• 343 tests pass with MOB_DIR and MOB_DEV_DIR configured
• mix format --check-formatted
• mix compile --warnings-as-errors
• mix credo --strict
• native Moto consumer build and Mob.Test.screen_info/1 returned 411.4286x914.2857 @1.75 with nonzero 43.4286/48 top/bottom insets, matching adb 720x1600 @280dpi

Downstream: app-ii3

[GenericJam]

Adversarially reviewed and device-verified.

Contract check (cross-repo): mob 0.7.32 android/jni/mob_nif.zig caches screenInfo as optional ()[F and unpacks [w, h, scale, top, bottom, left, right] with splat-zero defaults and a clamped copy — exact match with this template's array order. Old bridges degrade gracefully; regenerated bridges upgrade cleanly.

Gates: 343/343 tests, mix format --check-formatted, compile --warnings-as-errors, credo --strict — all clean in a fresh worktree.

Physical Moto g power 2021 (Android 11, SDK 30 → exercises the R branch): fresh app generated from this branch (MOB_NEW_DIR pointed at the PR worktree), built and deployed. Mob.Test.screen_info/1 returned 411.4286×914.2857 @1.75 with top 43.4286dp / bottom 48dp — independently matches adb ground truth (720×1600 @280dpi; status bar frame 76px → 43.43dp). Rotation probe: forced landscape and re-queried — dims swapped live (914.29×411.43) and insets migrated correctly (cutout → left 40dp, navbar → right 48dp, top 24dp), proving per-call freshness rather than startup caching.

Non-blocking notes:

• The untimed latch.await() mirrors the adjacent getSafeArea() idiom, but the screenshot paths use 2s timed awaits — worth converging both on the timed form in a follow-up so a wedged UI thread can't hang a NIF scheduler.
• Pre-R fallback branch (decorView/rootWindowInsets) is string-asserted only; no pre-Android-11 hardware in the pool to exercise it. Defensive fallbacks look sane.
• Unrelated template gap found while verifying (beaded separately): generated .tool-versions omits the zig pin, so a first mob.deploy --native fails toolchain detection with a hint recommending zig 0.15.x when the build needs the 0.17.0-dev pin.

Merging.