[AWS::Logs::DeliverySource] - [BUG] - ResourceArn should be createOnly; Update with new ResourceArn is rejected at runtime

### Name of the resource

`AWS::Logs::DeliverySource`

### Issue Description

The current resource schema marks [`ResourceArn`](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-logs-deliverysource.html#cfn-logs-deliverysource-resourcearn) as `writeOnly` but does **not** include it in `createOnlyProperties`. This causes CloudFormation to plan an in-place `UpdateDeliverySource` when `ResourceArn` changes, but the underlying AWS Logs API rejects that call:

```
UPDATE_FAILED: (AWS::Logs::DeliverySource)
Resource handler returned message: "Update to existing Delivery Source with new ResourceId
is not allowed. Please create a new Delivery Source instead."
```

The schema and the runtime API disagree. Any stack whose `ResourceArn` is wired to a `!GetAtt` on a sibling resource (e.g. an AgentCore `Runtime`, an NLB, etc.) will hit this the moment that sibling is replaced, leaving the stack in `UPDATE_FAILED`.

There's also a related failure mode when `Name` (which IS `createOnly`) changes but `ResourceArn` doesn't — CFN plans a Create-then-Delete swap, but the Create fails because AWS Logs enforces one `DeliverySource` per `ResourceArn`:

```
CREATE_FAILED: (AWS::Logs::DeliverySource)
Resource handler returned message: "This ResourceId has already been used in another
Delivery Source in this account." (HandlerErrorCode: AlreadyExists)
```

Both stuck states only resolve by manually deleting the existing `DeliverySource` (plus its `DeliveryDestination` and `Delivery`) via the AWS CLI and redeploying.

### Expected Behavior

Two changes:

1. **Mark `ResourceArn` as `createOnly`** in the resource schema. CloudFormation will then plan a Replacement when `ResourceArn` changes, not an in-place Update — matching the actual AWS Logs API behaviour.

2. **Sequence the Replacement as Delete-then-Create** (rather than the default Create-then-Delete) when `ResourceArn` is the changing property. Two `DeliverySource`s can't share a `ResourceArn`, so the default order collides with the existing resource. The CFN handler can implement this via the resource provider's `update` handler.

### Observed Behavior

Two distinct stuck-deploy scenarios as described above. Both require manual AWS CLI cleanup to recover.

### Test Cases

**Mode 1 (Update path):**

1. Deploy a stack with `AWS::Logs::DeliverySource` whose `ResourceArn` is `!GetAtt SomeReplacementTriggeredResource.Arn`.
2. Modify a `createOnly` property on `SomeReplacementTriggeredResource` so it must be replaced.
3. Deploy. CFN attempts `UpdateDeliverySource` on the existing DeliverySource with the new ARN, the API rejects it, the stack lands in `UPDATE_FAILED`.

**Mode 2 (Replace path with ResourceArn unchanged):**

1. Deploy a stack with `AWS::Logs::DeliverySource` having `Name: foo`, `ResourceArn: `.
2. Change the `Name` property to `Name: bar`. `Name` is `createOnly`, so CFN plans a Replacement.
3. Deploy. CFN tries to create a new DeliverySource with `Name: bar` and the **same** `ResourceArn`. The API rejects with `AlreadyExists` because the existing `foo` DeliverySource still holds that `ResourceArn`.

### Other Details

Background context: hit this twice across a single deploy cycle for an AWS Bedrock AgentCore Runtime logging setup. Each occurrence required ~30 min of manual AWS CLI cleanup per affected region.

Start with the AWS::Logs::DeliverySource resource schema and its resource provider update handler. Confirm how ResourceArn changes are classified and how replacement ordering is controlled, then verify that ResourceArn triggers replacement, the replacement deletes before creating when required, and both reported failure modes are covered by tests.

Written by the indexing model from the issue text.