fix(android): follow system theme so WebView sees correct prefers-color-scheme

[TimeToBuildBob]

Problem

Closes #300.

When the user selects "System" in aw-webui's theme picker, the JS hook reads
window.matchMedia('(prefers-color-scheme: dark)').matches. On Android, this
value is derived from the Activity's effective night mode configuration, not
directly from the system setting.

The old base theme was Theme.AppCompat.Light.NoActionBar, which forces the
Activity into light mode regardless of the OS setting. So prefers-color-scheme
always returned light, and "System" was indistinguishable from "Light".

Erik confirmed this: the setting "becomes light mode for me, despite in system
dark mode at 01:46 AM."

Fix

Three small changes that work together:

1. AWApplication.kt (new): calls AppCompatDelegate.setDefaultNightMode( MODE_NIGHT_FOLLOW_SYSTEM) in Application.onCreate(). This wires the
   process-wide night mode to the OS setting before any Activity starts,
   so there is no Activity recreation — the Activity simply starts in the
   correct mode.

2. styles.xml: changes AppTheme parent from
   Theme.AppCompat.Light.NoActionBar to Theme.AppCompat.DayNight.NoActionBar
   so the theme properly responds to the night mode configuration.

3. values-night/colors.xml: adds default_text_color = #FFFFFF so the
   existing android:textColor override in AppTheme doesn't produce black text
   on dark backgrounds.

The native chrome (system bars, drawer) already adapts via applyWebUiChrome()
in MainActivity — those codepaths are unchanged.

Why not AppCompatDelegate at runtime?

PR #276 explicitly avoided AppCompatDelegate to prevent Activity recreation
and WebView reload. That concern applies to switching the night mode while
the app is running. Setting MODE_NIGHT_FOLLOW_SYSTEM in Application.onCreate()
is different: the mode is fixed at process start, so the Activity is born in the
correct mode and never needs to recreate.

Tests

• AWApplicationTest.kt: verifies the class exists and inherits from Application
• Existing WebUiThemeTest and MainActivityNavigationTest unchanged

[greptile-apps]

Confidence Score: 5/5

The implementation appears safe to merge; the remaining issue is non-blocking test coverage that does not exercise manifest registration or startup night-mode behavior.

Summary

This PR makes the Android activity follow the system night-mode configuration so WebView receives the correct prefers-color-scheme value.

• Registers a custom Application that selects MODE_NIGHT_FOLLOW_SYSTEM before activities start.
• Changes the application theme from AppCompat Light to DayNight.
• Keeps native Auth, Sync, and Onboarding text black against their explicitly light backgrounds.
• Adds unit coverage for the application class, AppCompat constant, and absence of a night text-color override.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Application process starts] --> B[AWApplication.onCreate]
    B --> C[Set MODE_NIGHT_FOLLOW_SYSTEM]
    C --> D[Activity starts with DayNight configuration]
    D --> E[WebView reads prefers-color-scheme]
    D --> F[Native screens apply chrome]
    F --> G[Auth / Sync / Onboarding remain light]
    F --> H[MainActivity matches Web UI scheme]

Loading

_{Reviews (2) · Last reviewed commit: "fix(android): keep native-screen text re..."}

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

CI-green and mergeable (Greptile 5/5) — waiting only on a maintainer click.

This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted.