ecs-fargate-az-impairment: subnet removal triggers full redeployment, contradicting README claim

The [readme](https://github.com/aws-samples/fis-template-library/blob/main/ecs-fargate-az-impairment/README.md) of `ecs-fargate-az-impairment` states that

> ECS does not evict running tasks when a subnet is removed from the service network config — only new task placements are blocked.

which contradicts the update service api guidelines [This parameter triggers a new service deployment.](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html#:~:text=for%20the%20service.-,This%20parameter%20triggers%20a%20new%20service%20deployment.,-awsvpcConfiguration%20%2D%3E%20(structure)).

I verified this on a Fargate service spread across 3 subnets: removing one subnet via UpdateService started a rolling deployment that replaced all tasks, including those in unaffected AZs. For this template that means the injected AZ failure runs concurrently with an unintended full redeployment, so the observed recovery is a blend of deployment mechanics and failure response rather than a clean AZ-down behaviour, as intended here.

Begin with ecs-fargate-az-impairment/README.md and the ECS UpdateService API guidance linked in the issue; reproduce the subnet-removal behavior on a Fargate service if the project setup allows it. Done means the template's documented behavior matches the observed deployment mechanics and clearly distinguishes the intended AZ impairment scenario from any redeployment.

Written by the indexing model from the issue text.