Recurrence trigger: designer auto-appends "Z" to startTime, ignoring the specified non-UTC timeZone

### Severity

P2 - High (Major functionality broken)

### Describe the Bug with repro steps

**Summary**

When a Recurrence trigger has a non-UTC `timeZone` (e.g. `Tokyo Standard Time`) and a `startTime` written **without** the `Z` (Zulu) suffix (`yyyy-MM-ddThh:mm:ss`), the designer automatically appends `Z` to `startTime` after auto save completes and the user navigates away. Because the `Z` suffix forces UTC interpretation, the specified `timeZone` is effectively ignored and the workflow runs in UTC instead of the intended local time.

**Impact**

This happens **silently**. The workflow still saves and runs successfully, so the problem is very hard to detect. Users who correctly configured `startTime` without `Z` (as documented) end up with schedules that fire at the wrong local time (off by the UTC offset, e.g. 9 hours for JST).

**Repro steps**

1. Add a Recurrence trigger. Set **Time zone** to `(UTC+09:00) Osaka, Sapporo, Tokyo` and **Start time** to `2026-07-01T09:00:00` (i.e. `yyyy-MM-ddThh:mm:ss`, **without** a trailing `Z`).
2. Wait for **auto save** to complete, then navigate away from the page (e.g. switch to another view).
3. Reopen the workflow / view the code (or the version history).

**Actual**

`startTime` has been automatically rewritten to `2026-07-01T09:00:00Z`. The `Z` suffix was added by the designer during auto save, without any user action. Since `Z` denotes UTC, the configured `timeZone` (`Tokyo Standard Time`) is ignored and the trigger fires in UTC.

**Expected**

The designer must not modify a user-provided `startTime`. When a non-UTC `timeZone` is specified, `startTime` should remain without the `Z` suffix so the value is interpreted in the specified time zone, as described in the docs:
https://learn.microsoft.com/azure/connectors/connectors-native-recurrence?tabs=consumption#add-the-recurrence-trigger

**Suspected Root Cause**

The auto save serialization/normalization logic appends the `Z` designator to `startTime`, without accounting for the presence of a non-UTC `timeZone`.

**Workaround**

Switch back to the previous designer UI. The `Z` suffix is not appended to `startTime` when using the old designer.

### What type of Logic App Is this happening in?

Consumption (Portal)

### Are you experiencing a regression?

_No response_

### Which operating system are you using?

Windows

### Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg

Yes

### Workflow JSON

```json
{
"definition": {
"metadata": {
"notes": {}
},
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"contentVersion": "1.0.0.0",
"triggers": {
"Recurrence": {
"type": "Recurrence",
"recurrence": {
"interval": 3,
"frequency": "Minute",
"startTime": "2026-07-01T09:00:00",
"timeZone": "Tokyo Standard Time"
}
}
},
"actions": {},
"outputs": {},
"parameters": {
"$connections": {
"type": "Object",
"defaultValue": {}
}
}
},
"parameters": {
"$connections": {
"type": "Object",
"value": {}
}
}
}
```

### Screenshots or Videos

https://github.com/user-attachments/assets/c2322575-f11e-48c4-b4a2-d9d457f017d4

### Environment

N/A

### Additional context

_No response_

Reproduce the issue in the Consumption Logic Apps designer using a Recurrence trigger with a non-UTC timeZone and a startTime without Z. Trace the auto-save serialization or normalization path for the trigger; done means the designer preserves the user-provided startTime and the configured time zone remains effective after navigating away and reopening the workflow.

Written by the indexing model from the issue text.