android: Follow the system night mode on the host-driven path

[Bombatomica64]

On the host-driven entry point (android::host), the GPUI window does not follow the system's dark mode. This PR reads night mode from the host Activity and applies it at the points where it can change.

Problem

• query_night_mode_via_jni() reads the configuration through AndroidApp's AssetManager. The host-driven path has no AndroidApp, so the window stayed Light whatever the system used.
• Platform::window_appearance always answered Dark, on either path.

Change

• Without an AndroidApp, night mode is read from the application context's getResources().getConfiguration().uiMode. The first set_host_activity keeps that context for the life of the process. Its configuration follows system-wide changes whatever the Activity in front handles itself, whereas an Activity that lists uiMode in configChanges keeps its creation-time configuration in its AssetManager.
• The host path applies the system appearance when a window first opens, when a recreated Activity's surface is attached, and on resumed (the mode may have changed while another app was in front).
• New host::configuration_changed(). An Activity that handles uiMode itself must call it from onConfigurationChanged, otherwise its window keeps the old mode until it is resumed. It syncs every host's window, so stacked Activities follow too. Like MainEvent::ConfigChanged on the android-activity path, it also calls notify_keyboard_layout_change, so that now runs on every configuration change the host forwards.
• window_appearance returns the same value.

The android-activity path reads night mode as before; only window_appearance changes there.

Screenshots

The system switched to dark while the app was open. Left: without this change, the window stays Light. Right: with it. (OnePlus CPH2581, Android 16, host-driven test app.)

Testing

• cargo fmt --all -- --check, cargo clippy --target aarch64-linux-android --lib: no new warnings.
• On a OnePlus CPH2581 (Android 16), with a host Activity that lists uiMode in configChanges: cold start in light and in dark; switching to dark while the app is in front (configuration_changed); and switching back to light while it is in the background, then returning to it. In that last case Android delivers onConfigurationChanged just before onResume, so the resumed sync is there for hosts that do not forward configuration changes.
• Before the change, on the same device, the window stayed Light after switching to dark.

Test app: Bombatomica64/Gpui-android (its Diagnostics screen shows the window and platform appearance).

The emoji font on the host path is a separate PR (#29), since it does not depend on this one.

🤖 Generated with Claude Code

[huacnlee]

Thanks for following up on the night-mode note from #29. A few things to fix before merging. These come from reading the diff; I have not checked them on a device.

1. The android-activity path still starts Light, and now disagrees with the platform (jni.rs, InitWindow branch)
Platform::window_appearance() now returns the real night mode, but the android-activity InitWindow path (platform.open_window and the init_window reattach) never calls sync_appearance. On a cold start in dark mode, cx.window_appearance() says Dark while the window's appearance() stays Light until a ConfigChanged, and observe_window_appearance never fires. Before this PR both paths at least agreed on Dark; now they disagree.

2. Sync the initial appearance in the shared code, not only at host.rs call sites (host.rs)
The initial sync is added in three host-only places (new window, reattach, resume). Calling sync_appearance inside AndroidPlatform::open_window (and after init_window) would fix both entry points in one place and resolve item 1.

3. The application context ignores app-local night mode (jni.rs, host_ui_mode)
Night mode is read from getApplicationContext().getResources().getConfiguration(). An app-local setting such as AppCompatDelegate.setDefaultNightMode changes only the Activity's configuration, so an app with an in-app dark-theme toggle would be dark everywhere except the GPUI window. Please read the Activity's Resources instead.

4. configuration_changed depends on the order Android delivers config changes in (host.rs)
Inside onConfigurationChanged, the code reads the application's configuration, assuming the process-level change has already been applied. Process and Activity configuration changes are separate transactions, so this can read a stale uiMode. Passing newConfig.uiMode from the callback into configuration_changed would remove that dependency.

Non-blocking:

• window_appearance() now makes several JNI calls on every call on the host path, and builds a new AConfiguration each time on the android-activity path. Theme code that calls it during render pays that cost every frame. Returning the appearance already stored by sync_appearance would cost nothing and stay consistent with PlatformWindow::appearance.
• The ConfigurationChanged handler runs the same process-wide query once per window. Query once before the loop and call set_appearance on each window.
• host_ui_mode errors are swallowed by is_ok_and, so a failed context capture silently means Light forever. Please log a warning.

[Bombatomica64]

Thanks for the review, and sorry for the silent force-push on the 12th: that
was only a rebase onto #29 and did not address anything. The fixes are in
fa0075b, on top of it:

1. android-activity path starts Light. Fixed by item 2. On a cold start in
   dark mode, cx.window_appearance() and window.appearance() both say Dark
   on the first frame now. Before, the window said Light.
2. Sync in the shared code. AndroidPlatform::open_window applies the night
   mode, and so does a new AndroidPlatform::reinit_window, which both
   InitWindow and the host's reattach now use instead of calling
   init_window directly. The call-site syncs in host.rs are gone. Only
   resumed still re-reads it, in case it changed while another app was in
   front.
3. App-local night mode. uiMode now comes from the current host Activity's
   Resources, so AppCompatDelegate.setDefaultNightMode counts. With the
   application context no longer needed for night mode, I dropped the global
   this PR had added. The AssetManager is fetched as on main again.
4. Order of config changes. It's now host::configuration_changed(ui_mode: i32),
   and the host passes newConfig.uiMode. Nothing re-reads a configuration in
   that path. The module docs show the call.

Non-blocking:

• The platform stores the appearance it last applied, and
  window_appearance() just returns it, with no JNI call or AConfiguration.
  It has its own small lock rather than living in the platform state, because
  GPUI reads it from main-thread tasks, and flush_main_thread_tasks() runs
  those with the state locked. My first version stored it in the state and
  deadlocked on the first night-mode change on the android-activity path.
  The device test below caught it.
• ConfigurationChanged reads the night mode once and applies it to every
  window (AndroidPlatform::set_appearance).
• A failed uiMode read logs a warn!. The read also runs in a local frame
  now, since the render thread never returns to Java.

Tested on a OnePlus with Android 16, switching with cmd uimode night:

• host path (Bombatomica64/Gpui-android, Diagnostics screen): cold start in
  dark mode, a live toggle to light (the Activity handles uiMode), back to
  dark while in the background then resumed, and a light system with the
  Activity forced to dark the way AppCompat does it. All four show the right
  appearance.
• android-activity path (this repo's example, with a log in an
  observe_window_appearance callback): a cold start in dark mode logs
  platform=Dark window=Dark (ec5c89d logged platform=Dark window=Light), and
  toggling light and back fires the observer each time with both values
  agreeing.

One API change for hosts: configuration_changed now takes the uiMode
argument.