GeezerVison

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#running-unit-tests-application.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

• On Android, Application.systemAppearance(), orientation() and layoutDirection() throw until Application.run() has initialized the module, because they read the configuration from Application.android.context. A theme module imported by the app's entry cannot read the appearance.
• Utils.android.setDarkModeHandler() keeps the first handler it is given and ignores later ones. setStatusBarColor() and setNavigationBarColor() never change a color: they assign with ??= onto settings that always start with default colors. All three store the settings under the current activity rather than the one passed in, so refreshEdgeToEdge() on that activity loses them.
• Application.systemAppearanceChanged(rootView, appearance) does nothing while setAutoSystemAppearanceChanged(false) is in effect, so an app that turned automatic changes off to choose its own appearance has to turn them back on around each call.

What is the new behavior?

• The Android trait getters read the configuration from the native application when the context is not set yet. The app's code runs from the native application's onCreate, so it exists by then.
• The setters replace the handler and the colors they are given, keep the colors they are not given, and store the settings under the activity passed in.
• autoSystemAppearanceChanged gates only the automatic path, where the system's appearance changes. The event still fires there. An explicit systemAppearanceChanged() call applies the classes.

Tests: application/system-appearance.spec.ts (4) and utils/edge-to-edge.android.spec.ts (3).

Verified with all of these core PRs merged together (#11527–#11537): apps/automated passes on the iOS 26.4 simulator (1830 OK, 0 failed) and on an Android API 36 emulator (1692 OK; the one failure is the network-dependent IMAGE-CACHE.test_ImageCache_ValidUrl timeout, which also passes on reruns).