Batch 1 of the 60: the two that change what the app can be trusted with.

BACKGROUND WATCHER finishes a promise the app has implied since the first
build. The run always continued server-side — the phone is only a window onto
it — but nothing told you it had landed unless the chat screen happened to be
open. A foreground service now polls /api/chats and raises a local notification
when a chat leaves the running set.

Detecting completion by diffing successive polls is the only option available:
there is no FCM here and the server has nothing to push with. The service seeds
its set on start, so a run already in flight when it launches is not instantly
reported as finished. The background isolate cannot see the app's providers, so
it re-reads the server and token from SharedPreferences and makes its one GET
with dart:io rather than carrying Dio across the isolate boundary.

Off by default. Android requires a persistent notification for a foreground
service, and one the user did not ask for is how an app gets uninstalled — so it
is a switch, set to LOW importance because the ping is the point, not the badge.

BIOMETRIC LOCK, because this app can now push to repositories that deploy to
clients and redeploy their infrastructure, and a phone left on a table should be
able to do neither. It re-evaluates on every return to the foreground, not only
at cold start: someone picking up an already-running phone is the actual risk.
A grace window avoids prompting on every glance.

Two deliberate choices: the device PIN is accepted as a fallback rather than
biometrics only, and a PlatformException opens the app instead of blocking it.
Locking someone out of their own tooling because a fingerprint enrolment was
lost would be worse than the risk being guarded. This gates the UI; it is not a
vault, and does not claim to be.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>