[ECS] [request]: Request for "LATEST" Platform Version returned for ECS services using a CODE_DEPLOY deployment controller.

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**

When an ECS service is created with `platformVersion: "LATEST"`, please return the literal string `LATEST` in `DescribeServices` / the console / the CLI **regardless of deployment controller** — including services using the blue/green (`CODE_DEPLOY`) controller.

Currently the representation differs by deployment controller for an otherwise identical configuration:

| Deployment controller | Created with | `DescribeServices` → `platformVersion` |
|---|---|---|
| `ECS` (default) | `--platform-version LATEST` | `LATEST` |
| `CODE_DEPLOY` | `--platform-version LATEST` | `1.4.0` |

**Which service(s) is this request for?**
ECS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

**Ease of use / consistency** — customers expect the same platform-version representation regardless of deployment controller. The same service definition (`platformVersion: "LATEST"`) reads back as `LATEST` on the default `ECS` controller and as `1.4.0` on `CODE_DEPLOY`, so identical intent produces two different-looking services in the console, the CLI, and in IaC state. Reconciling that difference is pure overhead: it makes Terraform/CloudFormation drift noisy (declared `LATEST` vs read-back `1.4.0`) and forces per-controller special-casing in any tooling or standard that reads the field.

* **Best practice** — many customers treat displaying `LATEST` as a good practice to signal they are tracking the newest platform version, even though the resolved value (`1.4.0`) already **is** the current latest for Linux ([Fargate platform versions for Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-fargate.html)). On a `CODE_DEPLOY` service that signal is simply unavailable.

And it is unavailable in a way the customer cannot fix:

1. `UpdateService --platform-version LATEST` is rejected:.

**Additional context**

* Reproduction :

Explicit platform version:

aws ecs create-service \
--cluster testing \
--service-name testing-svc \
--task-definition nginx-fargate \
--desired-count 1 \
--launch-type FARGATE \
--platform-version LATEST
--deployment-controller "type=CODE_DEPLOY" \
--load-balancers "targetGroupArn=” \
--network-configuration "awsvpcConfiguration={subnets=[subnet-0576c00584cef59af,subnet-02e68446addc2c63d],securityGroups=[sg-096fddb6e541e1962],assignPublicIp=ENABLED}" --region ap-southeast-1

Without platform version:

aws ecs create-service \
--cluster testing \
--service-name testing-svc2 \
--task-definition nginx-fargate \
--desired-count 1 \
--launch-type FARGATE \
--deployment-controller "type=CODE_DEPLOY" \
--load-balancers "targetGroupArn=” \
--network-configuration "awsvpcConfiguration={subnets=[subnet-0576c00584cef59af,subnet-02e68446addc2c63d],securityGroups=[sg-096fddb6e541e1962],assignPublicIp=ENABLED}" --region ap-southeast-1

- Both return the same 1.4.0 instead of LATEST

Start by reproducing the behavior with the AWS CLI create-service examples in the issue, using both ECS and CODE_DEPLOY deployment controllers. Compare the returned platformVersion from DescribeServices; done means a CODE_DEPLOY service created with platformVersion LATEST preserves and returns the literal LATEST consistently.

Written by the indexing model from the issue text.