(android) Block pointer events from falling through the screen-lock overlay

[PeterXMR]

Closes #733.

Summary

When the wallet is locked and showing "Unlock to continue", pointer events in empty regions of the lock overlay can reach interactive elements drawn on the destination underneath, allowing those underlying controls to be triggered without unlocking the wallet. The original report describes opening the "Add a custom description to this payment" sheet through the lock screen.

Change

Wrap the lock-prompt content in a Box whose pointerInput consumes any pointer event still unconsumed during the Final pass. Children with their own pointer handlers (the biometric / PIN code buttons inside the lock prompt) consume their events first during the Main pass, so the unlock controls remain interactive while empty-space taps no longer leak through.

phoenix-android/.../StartupView.kt only — LoadWallet's isScreenLockRequired == true branch. contentAlignment = Alignment.Center is set on the new Box so the snowflake icon and "Unlock to continue" text remain visually centered (matching master).

Verification

Manually verified on a Pixel 4a API 34 emulator with a wallet that has Lock PIN enabled (1-minute auto-lock):

1. Navigate to Receive → Lightning.
2. Send the device to sleep via KEYCODE_POWER to trigger ACTION_SCREEN_OFF → clearActiveWallet() and re-enter the locked state.
3. Wake the device and dismiss the auto-popped PIN sheet (Back).
4. With "Unlock to continue" + the bottom PIN code button visible, tap at coordinates (574,1522), (354,1358), (726,1358) — these match where the underlying Lightning Receive screen's "Add amount and description" link, "Single use" tab, and "Reusable" tab live.

A/B comparison:

• master: the first tap caused the underlying screen's element to fire — the PIN sheet opened and subsequent taps registered as digit input (screenshot diff visible).
• this PR: all three taps produce byte-identical screenshots — no state change, no underlying element triggered.

Tap on the lock screen's own "PIN code" button still opens the PIN sheet, confirming that the legitimate interactive elements of the lock prompt remain reachable.

Test plan

• Build passes (:phoenix-android:assembleDebug)
• Functional A/B on emulator: tap-through no longer triggers underlying screen
• Lock screen's PIN code button still responds normally