FakeStore install sessions hang when PackageInstaller returns STATUS_PENDING_USER_ACTION on Android 14+

FakeStore can leave installs or updates stuck when PackageInstaller returns STATUS_PENDING_USER_ACTION.
FakeStore receives the confirmation intent from PackageInstaller.EXTRA_INTENT, but currently tries to start that activity directly from its session result receiver. On Android 14+ this can be blocked by background activity launch restrictions, so the required confirmation dialog is never shown and the install appears to hang.

**To Reproduce**
Steps to reproduce the behavior:
1. On Android 14+ or Android 15, install an older version of an app through Aurora Store using the session installer.
2. Switch the install/update source to microG FakeStore.
3. Try to update the same app through FakeStore.
4. Android requires user confirmation because the installer changed, the install may remain stuck instead of showing the confirmation dialog.

Alternative (my original problem):
1. Install a base app through Aurora Store that uses split install.
2. Use a feature in that app that triggers a Play Core dynamic feature/split install through FakeStore.
3. PackageInstaller requires confirmation, the split install may stay at 0% or "initializing"

**Expected behaviour**
When PackageInstaller returns STATUS_PENDING_USER_ACTION, FakeStore should show the required confirmation to the user, for example through a notification PendingIntent or "requires user confirmation" , instead of trying to launch the confirmation activity directly from the background.

**Observed behaviour**
Install seems to stall, split install sticks indefinitely at 0%

**System**
Android Version: 15 (but would happen on 14)
Custom ROM: Sailfish OS AppSupport 15

**Additional context**
I think this is related to #3541 and PR #3543: `UPDATE_PACKAGES_WITHOUT_USER_ACTION` / `USER_ACTION_NOT_REQUIRED` is still useful, but FakeStore still needs to handle `STATUS_PENDING_USER_ACTION` because Android can require confirmation for valid reasons, such as installer-of-record/update-owner mismatch or any other corner case. The extra component between the UI and the PackageInstaller seems to be the cause. Maybe in this case a fallback to a notification `PendingIntent` like I think you already do in the case of a locked-screen could catch everything potentially stuck here. For the split installs, then perhaps reporting the "requires user confirmation" session state back to the app, and it can handle asking for it?

Start by tracing FakeStore's PackageInstaller session result receiver and its handling of STATUS_PENDING_USER_ACTION and PackageInstaller.EXTRA_INTENT. Reproduce the Android 14 or 15 install and inspect how the confirmation intent is launched from the background. Done means the required confirmation is presented and normal installs, updates, and split installs no longer remain stuck.

Written by the indexing model from the issue text.