fix(webview): preserve login WebView state across rotation (#46)

[jim-daf]

Closes #46.

Rotating the device while the login WebView has navigated several pages deep snapped the page back to the initial login URL. The activity rebuilt the WebView and called loadUrl unconditionally on every recreate.

This change persists the WebView via onSaveInstanceState and restores it on recreate, falling back to the initial load when there is no snapshot. The QQ-login path gets the same treatment for consistency.

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    binding?.loginByWebWebview?.saveState(outState)
}

if (savedInstanceState != null) {
    binding!!.loginByWebWebview.restoreState(savedInstanceState)
} else {
    binding!!.loginByWebWebview.loadUrl(URLUtils.getLoginWebURL(discuz!!))
    binding!!.loginByWebWebview.clearCache(true)
}

[Copilot]

Pull request overview

This PR aims to preserve the login WebView navigation state across configuration changes (e.g., device rotation) by restoring WebView state instead of always reloading the initial URL.

Changes:

• Add an optional savedInstanceState parameter to configureQQLoginWebview.
• Restore the QQ-login WebView via WebView.restoreState(savedInstanceState) when a state bundle is available, otherwise fall back to loadUrl(url).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

savedInstanceState is never passed by any call site (current call at configureIntentData() still calls configureQQLoginWebview(url)), and this Activity does not override onSaveInstanceState() to call WebView.saveState(). As a result, restoreState() will never run and rotation will still reset the QQ-login WebView. Thread savedInstanceState from onCreate() through configureIntentData() into configureQQLoginWebview(), and persist the WebView state in onSaveInstanceState() (optionally in a dedicated sub-Bundle key) so the restore path has real data.

[Copilot]

restoreState() is invoked before the WebView is configured (settings + webViewClient). If restore triggers any loads/navigation, those requests may run with the default client/settings and bypass CookieWebViewClient. Set up the WebView (at least webViewClient, and required settings like JS) before calling restoreState() / loadUrl() to keep behavior consistent.