(applicationsignals-alpha): deployment fails on windows hosts with user/password error

### Describe the bug

When attaching application-signals functionality to a windows conainter it fails to deploy with the following error on the cloudwatch-agent container:

> CannotStartContainerError: Error response from daemon: container 1800c3f9395a4353c70a4f793900a4986988604db812cfd0f45d0eb16ee4763b encountered an error during hcs::System::CreateProcess: start-amazon-cloudwatch-agent.exe: failure in a Windows system call: The user name or password is incorrect. (0x52e)

Currently the cloudwatch-agent container has it's user set to '0:1338':

https://github.com/aws/aws-cdk/blob/0bce2f0d61821920728d337fba2d23276e2b61ec/packages/%40aws-cdk/aws-applicationsignals-alpha/lib/enablement/ecs-cloudwatch-agent.ts#L166

This is only valid for Linux hosts but is being set irrespective of the OS. This is not valid for windows hosts as per the CF documention here:

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#:~:text=uid%3Agroup-,Note,-This%20parameter%20is

### Regression Issue

- [ ] Select this option if this issue appears to be a regression.

### Last Known Working CDK Library Version

_No response_

### Expected Behavior

On windows hosts the container user field is not set.

### Current Behavior

CannotStartContainerError: Error response from daemon: container 1800c3f9395a4353c70a4f793900a4986988604db812cfd0f45d0eb16ee4763b encountered an error during hcs::System::CreateProcess: start-amazon-cloudwatch-agent.exe: failure in a Windows system call: The user name or password is incorrect. (0x52e)

### Reproduction Steps
```
const taskDefinition = new ecs.Ec2TaskDefinition(
this,
'TaskDefinition',
{
networkMode: ecs.NetworkMode.NAT,
taskRole,
},
);

taskDefinition.addContainer('windowsservercore', {
logging: ecs.LogDriver.awsLogs({ streamPrefix: 'win-iis-on-fargate' }),
portMappings: [{ containerPort: 80 }],
image: ecs.ContainerImage.fromRegistry('mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022'),
});

new appsignals.ApplicationSignalsIntegration(
this,
'ApplicationSignalsIntegration',
{
taskDefinition,
instrumentation: {
sdkVersion:
appsignals.DotnetInstrumentationVersion
.V1_7_0_WINDOWS2022,
runtimePlatform: {
cpuArchitecture: ecs.CpuArchitecture.X86_64,
operatingSystemFamily,
},
},
serviceName: 'windowsservercore',
cloudWatchAgentSidecar: {
containerName: 'cloudwatch-agent',
enableLogging: true,
operatingSystemFamily,
essential: false,
cpu: 256,
memoryLimitMiB: 512,
},
},
);
```
### Possible Solution

Set the user to undefined for windows containers

### Additional Information/Context

Escape-hatch workaround (index will be variable depending on your task definition):

```
const cfnTaskDef = taskDefinition.node.defaultChild as ecs.CfnTaskDefinition;
cfnTaskDef.addOverride('Properties.ContainerDefinitions.2.User', undefined);
```

### AWS CDK Library version (aws-cdk-lib)

2.197.0

### AWS CDK CLI version

2.1016.1 (build 6de56b2)

### Node.js Version

24.0.1

### OS

Windows 11/Windows Server 2022

### Language

TypeScript

### Language Version

_No response_

### Other information

_No response_

Start in packages/@aws-cdk/aws-applicationsignals-alpha/lib/enablement/ecs-cloudwatch-agent.ts, around the user setting referenced in the issue, and compare it with the Windows reproduction. Verify the generated task definition leaves the container user unset for Windows hosts while preserving the existing behavior for Linux hosts.

Written by the indexing model from the issue text.