[trypsynth]

For #152

Problem

Devin's retest on build 318 showed 13 main-thread blocks of 101 to 275 ms when the watch screen turns on. Six of them are FocusActorForScreenStateChange.restoreLastFocusedNode -> FocusActionRecord.getFocusableNodeFromFocusRecord -> AccessibilityNodeInfo.refresh, waiting 101 to 298 ms. When the screen turns on, the app in front is busy drawing again, and the first request sent to it waits until that's done. Moving just that refresh() to another thread wouldn't help, because restoring focus then sends performAction to the same busy app from the main thread.

Change

• New focusmanagement/WakeFocusWarmUp.kt. It fetches the last focused item on a background thread, then runs the restore on the main thread once the app has answered, when its requests are quick. If the app hasn't answered after 500 ms, the restore runs anyway, as before.
• FocusProcessorForScreenStateChange.onScreenStateChangedInternal uses it only for the first screen state after waking, when there is a focus record for the active window. Everything else runs at once, as before.
• A waiting restore is dropped when the screen state changes again, and skipped if focus was moved while the app was answering, so it never takes focus away from the user.
• differences.md has a paragraph under Faster screen changes.

Testing

• WakeFocusWarmUpTest: the restore waits for the app, runs once after the timeout, is dropped by cancel, and a later request drops an earlier one.
• :talkback:testPhoneDebugUnitTest (540 tests), :lintPhoneDebug, :lintWearDebug, assemblePhoneDebug and assembleWearDebug pass.
• Not measured on a device. Devin offered a wrist-raise pass on Wear OS 6 (Galaxy Watch 5 Pro): first utterance after a service restart 0.06-1.2 s late, and display-state work blocks the main thread up to 1.6 s #152, which would show whether the restoreLastFocusedNode blocks are gone, and whether focus still comes back to the right item on wake.