[hoanle0126]

Previously, reConnectFlutterDriver cleared LogMonitor.lastMatch inside getObservatoryWsUri after activateApp or mobile: activateApp / mobile: launchApp had already finished. This caused two issues:

1. Any new observatory URL logged while the proxy driver was launching the app was cleared before waitForLastMatchExist checked for it.
2. When activateApp or mobile: activateApp brought an already-running backgrounded app back to the foreground, no new observatory log line was emitted, so clearing lastMatch caused waitForLastMatchExist to time out after 10 retries.

This change clears LogMonitor.lastMatch before invoking the proxy launch/activation command so log entries emitted during launch are retained, and when activating an app that produces no new log line, tries reconnecting against the previous observatory match first before falling back to waiting for a new log entry. It also pauses and resumes newCommandTimeout in driver.activateApp(appId) to match mobile: activateApp.

Fixes #810

[KazuCocoa]

Could we leave new-command timeout management to BaseDriver.executeCommand here? For the regular activateApp command in the FLUTTER context, FlutterDriver.executeCommand delegates to super.executeCommand, which already clears the timeout before invoking this method and restarts it in its finally block after the awaited reconnect finishes. The additional clearNewCommandTimeout() and try/finally with startNewCommandTimeout() here therefore duplicate that handling.

Please keep the reconnectAfterAppLaunch(...) call itself. The timeout wrapper in the mobile: activateApp / mobile: launchApp branch should also remain, since that branch bypasses super.executeCommand. A timeout test through executeCommand would exercise the normal command lifecycle; the current test calls activateApp directly.

[hoanle0126]

Updated activateApp to rely on BaseDriver.executeCommand for newCommandTimeout handling while keeping reconnectAfterAppLaunch(...) and the timeout wrapper on mobile: activateApp / mobile: launchApp, and updated the test to run activateApp through executeCommand. Thanks @KazuCocoa!