[Logic Apps Hybrid] Adding a File System connection is not idempotent / doesn't safely preserve existing volume mounts (duplicates & corrupts azurestorageaccounts/template.volumes)

## Platform

**Azure Logic Apps _Hybrid_** (Azure Container Apps on connected/Arc environment). A parallel non-hybrid (Logic Apps Standard on App Service, `Microsoft.Web/sites/config/azurestorageaccounts`) path exists in the same client and is noted below.

## Summary

Adding a **new** File System connection mutates the container app's `template.volumes` / `template.volumeMounts` (hybrid) or `azurestorageaccounts` (Standard) in a way that **does not safely preserve prior mounts**, corrupting existing volume-mount configuration (including, in combination with #9438, the reserved `/home/site/wwwroot` mount).

## Where it happens (code)

`FileSystemConnectionCreationClient.ts` — same files as #9438:
- **AzureUX-LogicAppsPortal**: `src/Extension/Client/React/Services/FileSystemConnectionCreationClient.ts` (+ `CodelessWorkflows/Services/` mirror).
- **LogicAppsUX**: `apps/Standalone/src/designer/app/AzureLogicAppsDesigner/Services/FileSystemConnectionCreationClient.ts`.

### Hybrid branch (~L167–247)

```ts
const newVolumes = [ { name: fileShareName, storageName: fileShareName, storageType: 'Smb' },
...containerAppResponse.properties.template.volumes ];
const newVolumeMounts = [ { volumeName: fileShareName, mountPath: `/mounts/${fileShareName}` },
...containerAppResponse.properties.template.containers[0].volumeMounts ];
```

Problems:
1. **Not idempotent** — it unconditionally *prepends*. Re-saving the same connection, or reusing a `displayName`, appends duplicate `volumes`/`volumeMounts` entries for the same share.
2. **Only `containers[0]`** is updated; mounts on other containers are dropped when the reconstructed template is PATCHed back.
3. The reconstructed template becomes the write-back source of truth (see #9438), so any drift drops existing mounts.

### Non-hybrid branch (~L248–285)

```ts
const response = await httpClient.post(configFetchUrl, ...); // POST azurestorageaccounts/list
response.properties[connectionName] = newFileShareConfig; // merge
await httpClient.put(configBaseUrl, response, ...); // PUT full collection
```

This read-modify-writes the whole `azurestorageaccounts` dictionary. It preserves other entries **only if** the `/list` response returns every existing share with a usable `accessKey`; any masked/omitted entry is corrupted on write-back. Also emits a **Windows-style** mount path (`\mounts\` → `C:\mounts\`) which is invalid for **Linux** Logic Apps Standard.

## Suggested fix direction

- Key each mount by a **stable connector-specific name** and add/update only that entry (idempotent re-save); never blind-prepend.
- Preserve every existing `volume`/`volumeMount` (all containers) and never touch `/home/site/wwwroot` (see #9438).
- Non-hybrid: verify `/list` returns all shares with resolvable keys before PUT; emit an OS-appropriate `mountPath` (POSIX on Linux).

## Impact

**High** — File System connectors are not composable (duplicate/broken mounts), and existing mounts (incl. the runtime content mount) can be corrupted.

## References

- Internal work item: https://msazure.visualstudio.com/Antares/_workitems/edit/38598433
- Related: #9438 (save drops/repoints the `/home/site/wwwroot` mount).

Start with the hybrid and non-hybrid branches in FileSystemConnectionCreationClient.ts in the AzureUX-LogicAppsPortal and LogicAppsUX paths, then compare the CodelessWorkflows mirror. Trace how template.volumes, volumeMounts, and azurestorageaccounts are read and written, using #9438 for the related mount-preservation context. Done means re-saving is idempotent, all existing container mounts and shares remain intact, the reserved mount is untouched, and Linux paths remain POSIX-style.

Written by the indexing model from the issue text.