Respect per-app monitoring toggle when recording tracker access (#435)

[kasnder]

Fixes #435.

Problem

With Manage system apps on, a user turned monitoring off for the "GPS daemon" system app, yet the app list kept showing "contacted 1 company last week" (google.com). Clearing the tracker data made it reappear hours later. Expected: with per-app monitoring disabled, no new tracker-contact data should accrue for that app.

Root cause

The app-list count comes from access rows written by updateAccess(). That write is gated by shouldTrackApp(packet.uid):

• Write site: ServiceSinkhole.java:988 (application log -> dh.updateAccess(...))
• Gate: ServiceSinkhole.java shouldTrackApp(int uid)

shouldTrackApp() checked tracker protection (tracker_protect) and manage_system, but never the apply (monitoring) preference. Turning monitoring off adds the package to addDisallowedApplication (ServiceSinkhole.java:1713-1716, 1756-1758), so its own traffic bypasses the VPN — but traffic from system daemons sharing the same UID still reaches the tunnel. Because the count query (TrackerList.getTrackerCountsAndTotal()) is keyed by UID, those rows kept being written and displayed on the monitoring-off app, and re-accrued after a clear.

Fix

Add an apply/monitoring check to shouldTrackApp(), using a cached prefs handle refreshed in reload() — matching the existing cachedTrackerProtectPrefs pattern. When monitoring is off for the resolved package, no tracker access is recorded. This mirrors the VPN-exclusion semantics already applied when apply is false; blocking behaviour for monitored apps is unchanged, and no new setting is introduced.

Verification

• ./gradlew :app:compileGithubDebugJavaWithJavac passes.
• Needs on-device verification: with Manage system apps on, disable monitoring for a system app (e.g. GPS daemon / a shared-UID system component), clear its tracker data, and confirm over several hours that the "contacted N companies" line does not reappear, while blocking/monitoring of other apps continues normally.

🤖 Generated with Claude Code

[kasnder]

Review summary: I inspected the full diff and surrounding access-recording, preference reload, UID/package cache, shared-UID related-rule propagation, and app-removal invalidation paths. The apply preference is refreshed with the same lifecycle as the existing tracker-protection preferences, and related packages sharing a UID receive synchronized rule changes, so I did not find an actionable correctness or regression issue. The diff check is clean, and the refreshed GitHub test job passes.