App lock: cover the app instead of destroying it, and let debug builds lock at all

[mpretty-cyro]

The symptom

With app lock enabled, attaching a File to a message drops the user out of Session and the file is
never sent — no error, no toast, no failed-message bubble.

Two defects, and they only show together

1. <uses-permission> didn't match the <permission> declaration.

AndroidManifest.xml declares the permission with the build's postfix but asked for it without one:

<permission android:name="network.loki.messenger.ACCESS_SESSION_SECRETS${authority_postfix}" … />
<uses-permission android:name="network.loki.messenger.ACCESS_SESSION_SECRETS" />

KeyCachingService.handleClearKey broadcasts with "…ACCESS_SESSION_SECRETS" + BuildConfig.AUTHORITY_POSTFIX, so on any build with a non-empty postfix the app does not hold the
permission its own broadcast requires and the broadcast is dropped in silence. Only debug sets a
postfix (release/qa use ""), so app lock has never auto-locked anything in a debug build — a
security feature that silently does nothing in the build developers run all day, and the reason the
defect below was invisible locally.

2. Clearing the key destroyed the task.

onMasterSecretCleared() called finish() when the app was not visible. Every
ScreenLockActionBarActivity in the process receives that broadcast, so the whole task emptied —
including a conversation waiting on a picker result, whose onActivityResult then had nowhere to go.

Opening the SAF picker stops the process (ApplicationContext observes ProcessLifecycleOwner), and
the screen-lock timeout is 0 — getScreenLockTimeout defaults to 0, the only writer in the tree
also writes 0, and no setting exposes it — so the alarm fires while the picker is open, every time.

The lock is now presented in front of the activity and onStart re-checks on return, so the
activity and its pending result survive.

Scope of that claim: this preserves a direct return to the task — coming back from a picker,
camera or share sheet, which is the case attachment flows depend on. It does not make a conversation
survive re-entry from the launcher icon: HomeActivity is launchMode="singleTask" and the launcher
alias targets it, so that clears everything above Home regardless of this change.

Nothing was traded away for this

• the timeout stays 0 — "lock as soon as I leave" is the right posture, and raising it would trade
  security to hide this
• masterSecret is a sentinel Object, not a key ("only indicates if the app was unlocked or not"),
  so finishing evicted no cryptographic material
• BaseActionBarActivity already applies FLAG_SECURE in onPause for every activity, so a
  backgrounded conversation was never in the recents thumbnail whether or not it was finished

Second commit: review fixes

• Dismissing the lock without authenticating used to reveal the activity underneath, whose
  onStart presented the lock straight back — a loop escapable only via Home, and one that spun with
  no user input during a biometric lockout. Every non-authenticating exit now leaves the app.
  Worth knowing for anyone touching this: ScreenLockActivity is singleInstancePerTask, so it is the
  root of its own task above the app's, not stacked inside it — moveTaskToBack(true) therefore
  reveals the app again and does not work here. Back is routed through the same path; it previously
  bypassed the error handling entirely.
• A configuration change while stopped recreated the activity, and onCreate's route-and-finish
  path then discarded the pending result. hasStarted is saved/restored and the locked route is
  suppressed on a recreation, so onStart covers it instead.
• onMasterSecretCleared now applies the same isScreenLocked() guard as onStart:
  KeyCachingService.onDestroy broadcasts whether or not app lock is on, and ScreenLockActivity only
  prompts when the setting is on, so without it that broadcast could raise a lock screen with no way
  past it.
• onNewIntent no longer adopts an intent carrying no next_intent, which would discard the
  destination a routed unlock still has to reach.
• Restored the warning for a next_intent that has genuinely gone missing, distinguished from the
  expected-absent case by an explicit extra rather than by null alone.

Third commit: the zero timeout was never immediate

Backgrounding the app and coming straight back did not lock it, and this predates the whole PR.
startTimeoutIfAppropriate scheduled even a zero timeout through AlarmManager, which batches
non-wakeup alarms — measured delivery for an alarm set to "now" was ~5 seconds — and
onAppForegrounded cancels the pending alarm on the way back in. Any excursion shorter than the
batching delay therefore cancelled the lock before it happened, which with a timeout that is always 0
means every quick app switch:

App is no longer visible.
Starting timeout: 0
App is now visible.          ← no handleClearKey() between them, so no lock

Zero timeouts now send the existing expiry PendingIntent directly instead of scheduling it. That is
not a background service start — the branch is only reachable with a secret set, so
foregroundService() has already run — and it falls back to the old alarm if the PendingIntent has
been cancelled. Non-zero timeouts are unchanged. handleClearKey now runs 4ms after backgrounding
rather than ~5s.

This makes the lock noticeably stricter than the behaviour anyone has actually been using, because
until now the alarm delay was quietly forgiving every short trip. That is what a 0 timeout means and
what the setting promises, but if it proves too aggressive in practice the answer is the timeout
setting this code has never exposed, not an alarm that happens to be slow.

Testing

Pixel 6 / API 34 emulator with a device PIN, websiteDebug — which is itself the check on defect 1,
since that variant previously never received the broadcast:

handleClearKey()
onReceive() for clear key event      ← did not happen before
onMasterSecretCleared()
onReceive() for clear key event
onMasterSecretCleared()
        (no onDestroy)               ← the fix
Creating ScreenLockActivity
AttachmentDatabase: insertParts(1)

Unlocking returns to the same conversation with the file marked Sent. Also checked:
a two-second round trip out of the app and back now locks (the case the alarm delay used to swallow); Home then
reopen still demands authentication; a force-stop cold start still routes through STATE_SCREEN_LOCKED;
rotating the device while the picker is open keeps the attachment (onCreate logs has_started=true,
the locked route is skipped, the file still sends); and Back from a lock covering a live conversation
lands on the launcher having created exactly one lock screen.

Not covered by that testing

• The self-spinning ERROR_LOCKOUT case. Everything above was re-run with a fingerprint
  enrolled, so the BiometricPrompt path and its onAuthenticationError arms do now execute rather
  than falling back to createConfirmDeviceCredentialIntent — worth checking with
  adb shell dumpsys biometric | grep -i eligible before trusting any app-lock test result, since a
  bare emulator reports Ineligible … :7 and never runs that branch at all. Deliberately triggering a
  five-failed-attempts lockout is still untested.
• Declining the unlock does not preserve state — the conversation was gone on return. No worse than
  before, since the activity was already finished pre-PR, but not the same property as the picker case.
• A possible one-frame reveal. The lock starts from onStart, but the activity beneath also runs
  onResume, which clears FLAG_SECURE. Not observed, and not verified frame-by-frame. If it shows up,
  the answer is to blank content while locked rather than to go back to destroying the task.