PhoneWindowManager: honor disabled screen-on reclaim setting

[CeRRiLLo89]

Summary

Re-read SCREEN_ON_MEMORY_RECLAIM immediately before executing the delayed
screen-on memory reclaim.

Problem

PhoneWindowManager schedules mMemoryOpt from the cached
mScreenOnReclaim value and executes the callback 1250 ms later.

The callback previously called releaseMemoryAtScreenOn() without checking
the current setting again.

On raphael with crDroid Android 16, screen-on reclaim was reproduced while:

• the active user was 0;
• screen_on_memory_reclaim was 0;
• the exact-build mitigation module was disabled;
• the original services.jar was active.

One controlled screen-on cycle produced the reclaim log 1251 ms after wake
and killed 25 cached processes, including the Android Auto car process.

The exact reason for the stale cached state has not been proven. It may involve
setting-observer timing or cross-thread visibility.

Change

• Centralize the current setting lookup.
• Mark the cached flag volatile because it is updated and read from different
  execution contexts.
• Re-read the setting before the delayed callback releases memory.
• Preserve the existing reclaim behavior when the setting is enabled.
• Expose the delayed callback for unit testing with @VisibleForTesting.
• Isolate the two reclaim tests from the complete PhoneWindowManager
  initialization, because the callback only requires the settings context and
  the ActivityManager service.

This does not modify:

• LMKD
• ZRAM
• Cached App Freezer
• the reclaim interval
• the reclaim parameters
• system_server garbage collection

Tests

Added unit coverage verifying that:

• a disabled setting at callback execution prevents releaseMemory() from
  being called;
• an enabled setting at callback execution preserves the existing reclaim
  call.

The tests initialize only the dependencies required by the delayed reclaim
callback instead of initializing the complete PhoneWindowManager policy.
This avoids activating unrelated camera, role-management, device-key, and
Lineage settings subsystems during the unit test.

The ActivityManager call is mocked, so the tests do not perform a real process
reclaim.

Local validation was completed with the lineage_raphael userdebug target and
a physical Xiaomi Mi 9T Pro / Redmi K20 Pro (raphael) running Android 16 /
crDroid 12.11.

Executed tests:

WmTests:com.android.server.policy.PhoneWindowManagerTests#screenOnMemoryReclaimDisabledAtExecution_doesNotReleaseMemory

WmTests:com.android.server.policy.PhoneWindowManagerTests#screenOnMemoryReclaimEnabledAtExecution_releasesMemory

Result:

• WmTests compilation: passed
• Instrumentation installation: passed
• Tests selected: 2
• Passed: 2
• Failed: 0
• Disabled at execution: passed
• Enabled at execution: passed

The local crDroid WmTests baseline required two unrelated compatibility
adjustments in separate test files. Those adjustments were used only in the
local validation harness and are not included in this pull request.

Device context

Device: Xiaomi Mi 9T Pro / Redmi K20 Pro (raphael)

Build: crDroid Android 16 v12.11-20260623

Validated pull request head:

60a3492aa2756fdad29b5a502b6cfa8acfff9d73

The exact-build KernelSU mitigation remains enabled until a ROM build
containing this source change is available for controlled validation.

Validation status

• Controlled device reproduction: completed.
• Source review: completed.
• WmTests source compilation: completed.
• Targeted unit test execution: completed, 2 passed / 0 failed.
• Pull request test isolation update: completed.
• Device validation with a ROM build containing this change: pending.