[Android] Unexpected Behavior with Slow Async Calls and Swiped App with Running Foreground Service

### Description

# Unexpected Behaviours with Foreground Services in MAUI
## Issue Description

I start a Foreground Service (FGS) in my app. Then I start a potentially slow async call (maybe a API call). It takes too long, so I get bored, and swipe away the app. But app still exists, because of the FGS. When the async call finishes, what exactly should happen?

In this demo app, I have simulated a slow async call, and when it finishes, it navigates to a new page. This simulates a very common occurence of being taken to a stats screen following a completed API call with loads of data. But if the app has been swiped, how can navigation happen? The answer is it doesn't, and instead an exception is thrown. How should this be handled? Does every single navigation attempt need to be checked before initiated?

This is the exception created in this scenario:

Another weird quirk is with DisplayPromptAsync(), which is entirely ignored when the app is swiped. It is as if the code lines do not exist at all. This does not really cause any issues at least.

### Steps to Reproduce

1. Launch the app
1. Navigate to the ServiceControl page and start the Foreground Service (need to allow notifications to see the notification in the top bar)
1. Navigate back to HomePage and click the "Start Slow Async Task" button
1. Within ten seconds open app explorer and swipe away the app
1. Wait until the delay finishes, and observe result

### Link to public reproduction project repository

https://github.com/KillswitchPrime/MauiSlowAsyncWithFGS

### Version with bug

9.0.111 SR11.1

### Is this a regression from previous behavior?

Not sure, did not test other versions

### Last version that worked well

Unknown/Other

### Affected platforms

Android

### Affected platform versions

_No response_

### Did you find any workaround?

Possible workaround is to manually check every possible thing that can crash when the app is swiped with a FGS running, and then create specific cases to not execute code in these scenarios.

### Relevant log output

```shell

```