[CloudWatch] Logging worker cancellation spam with ExistingWorkPolicy.REPLACE

### Before opening, please confirm:

- [x] I have [searched for duplicate or closed issues](https://github.com/aws-amplify/amplify-android/issues?q=is%3Aissue+) and [discussions](https://github.com/aws-amplify/amplify-android/discussions).

### Language and Async Model

Kotlin

### Amplify Categories

Not applicable

### Gradle script dependencies

```kotlin
// Put output below this line

```

### Environment information

```
# Put output below this line

```

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

_No response_

### Describe the feature request

I am seeing frequent WorkManager cancellation warnings from the CloudWatch logging plugin. The stack shows cancellations of `CloudwatchRouterWorker/CloudwatchLogsSyncWorker` caused by `CancelWorkRunnable.forNameInline`, which aligns with `enqueueSync()` using `ExistingWorkPolicy.REPLACE`.

https://github.com/aws-amplify/amplify-android/blob/0d8783086ad2187528d4c7d45ea442c571144c1d/aws-logging-cloudwatch/src/main/java/com/amplifyframework/logging/cloudwatch/CloudWatchLogManager.kt#L255

Example log of the cancelation:

```
Work [ id=..., tags={ CloudwatchRouterWorker, CloudwatchLogsSyncWorker } ] was cancelled
WorkerStoppedException
… CancelWorkRunnable.forNameInline …
```

Is there a recommended way to avoid the cancellation spam? Would you consider using a different policy (e.g., KEEP or self‑rescheduling) or suppressing cancellation warnings?

### Initialization steps (if applicable)

_No response_

### Code Snippet

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

```

### Configuration File

_No response_

### GraphQL Schema

```graphql
// Put your schema below this line

```

### Additional information and screenshots

_No response_

Start in aws-logging-cloudwatch/src/main/java/com/amplifyframework/logging/cloudwatch/CloudWatchLogManager.kt around enqueueSync() at the referenced line. Trace how CloudwatchRouterWorker and CloudwatchLogsSyncWorker are enqueued and how WorkManager handles ExistingWorkPolicy.REPLACE. Done should mean the intended sync behavior is preserved without repeated cancellation warnings, with the chosen policy or logging behavior documented by the resulting change.

Written by the indexing model from the issue text.