[Authenticator] Improve documentation regarding navigation

### Before creating a new issue, please confirm:

- [X] I have [searched for duplicate or closed issues](https://github.com/aws-amplify/amplify-ui-android/issues?q=is%3Aissue+).
- [X] I have read the guide for [submitting bug reports](https://github.com/aws-amplify/amplify-ui-android/blob/main/CONTRIBUTING.md#reporting-bugsfeature-requests).

### Which UI component?

Authenticator

### Gradle script dependencies

```groovy
// Put output below this line
authenticatorVersion = "1.1.0"
```

### Environment information

```
# Put output below this line
Gradle 8.5
```

### Please include any relevant guides or documentation you're referencing

https://ui.docs.amplify.aws/android/connected-components/authenticator https://ui.docs.amplify.aws/android/connected-components/authenticator/customization#theming https://github.com/aws-amplify/amplify-ui-android/blob/main/samples/authenticator/app/src/main/java/com/amplifyframework/ui/sample/authenticator/MainActivity.kt https://developer.android.com/develop/ui/compose/navigation

### Describe the bug

What is the correct way to add Authenticator if you working on a Compose Android App that uses Jetpack Compose Navigation component?

It seems to me that there is conflicting and misleading documentation and code samples in the referred sources. There are basically two approaches that one can take:

1. Follow the sample code in the Theming documentation
In this case the whole application would be wrapped inside Authenticator and the MainActivity code would look something like this:
`MyApplicationTheme {
Authenticator(
signInContent = { signInState -> SignInScreen(signInState) }
) { state ->
val navController: NavHostController = rememberNavController()
MyAppNavHost(
authenticatorState = state,
navController = navController
)
}
}`

2. Follow the Authenticator sample code in GitHub
In this case we would use the mechanisms available in Compose navigation component and define e.g. AuthenticatorScreen() as a startDestination (= Authenticator.route) in NavHost. AuthenticatorScreen() would look something like this:
`@Composable
fun AuthenticatorScreen(
onShowSignedInContent: () -> Unit
) {
Scaffold { padding ->
Column(
modifier = Modifier
.fillMaxSize()
.padding(padding)
) {
Authenticator(
modifier = Modifier.fillMaxWidth(),
signInContent = { signInState -> SignInScreen(signInState) }
) { state ->
val activity = (LocalContext.current as? Activity)
(activity as MainActivity).signedInState = state
onShowSignedInContent()
}
}
}
}

And passed onShowSignedInContent lambda would do the navigating:
onShowSignedInContent = { navController.navigate(Main.route) }

In this case we have store signedInState somewhere because it can’t be passed as navigation argument.
Also, the screen containing the SignOut -action would receive the following lambda as parameter:
onSignOutClick = {
(activity as MainActivity).signedInState?.signOut()
navController.navigateSingleTopTo(Authenticator.route)
}`

I started experimenting with the 1) but noticed that there is a problem because Authenticator is not placed inside e.g. Scaffold that applies the correct colours from theme and I can’t really do that when using Compose navigation i.e. it’s included in Screen level composables. I then moved to 2) approach which seems to work but are there caveats in the way that you’re aware of? Also, there should be an API (e.g. Amplify.Auth.fetchCurrentState()) to fetch the current state to avoid need to store it in way shown above code.

So, the question is, which approach is the recommended one?

### Reproduction steps (if applicable)

_No response_

### Code Snippet

```java
// Put your code below this line.

```

### Log output

```
// Put your logs below this line

```

### amplifyconfiguration.json

_No response_

### Additional information and screenshots

_No response_

Compare the Authenticator navigation documentation, theming section, and the sample MainActivity.kt referenced in the issue, alongside the Android Compose Navigation guide. Determine which integration approach is recommended and whether the signed-in state handling and current-state API concerns need documentation changes. Done means the conflicting guidance and code samples are reconciled clearly.

Written by the indexing model from the issue text.