[Request]: Add network-scoped aliases for container network attachments

### Feature or enhancement request details

Please add network-scoped aliases for container network attachments.

#### Use case

Higher-level tools such as Compose adapters need to attach additional DNS names to a container on a specific network without changing the container's management name.

For example, a Compose service may have:

```yaml
services:
postgres:
networks:
backend:
aliases:
- db
- database
```

The runtime needs a way to represent those names as aliases for the same network attachment so peer containers on `backend` can resolve `postgres`, `db`, and `database` to the same attachment IP. The aliases should be scoped to the network attachment, not global host DNS.

This complements the broader container-to-container DNS discovery request in #1809.

#### UX / CLI shape

Use the existing comma-separated `--network` property syntax and allow repeated `alias=NAME` entries:

```sh
container run --network backend,alias=db,alias=database ...
container create --network backend,alias=db ...
```

Each `alias=NAME` applies only to that network attachment. Multiple networks can therefore carry different aliases for the same container.

#### Proposed design

At a high level:

- Extend network attachment options with an aliases array, alongside the existing primary hostname, MAC address, and MTU options.
- Parse repeated `alias=NAME` values from the existing `--network` option grammar.
- Carry aliases through the container API client, persisted attachment configuration, network helper allocation request, and returned attachment metadata.
- Treat the primary hostname and aliases as names for the same allocation in the hostname database.
- Validate duplicate names across active allocations before creating the container, so two attachments cannot claim the same hostname or alias in the same network.
- Normalize aliases using the same hostname lookup behavior as primary attachment hostnames, including case and trailing-dot handling, rather than introducing a stricter validator in this feature.
- Release all names for an allocation when the network attachment is released.

The draft implementation in #1815 follows this shape:

```sh
container run --network backend,alias=db,alias=database ...
```

In live validation against a debug build, peer containers on the same network could resolve the primary container name and both aliases through the container-facing network DNS listener, and a duplicate `alias=db` failed with the expected duplicate-hostname error.

#### Code of Conduct

I agree to follow this project's Code of Conduct.

Start by tracing the existing comma-separated --network parsing used by container run and create. Follow network attachment options through the container API client, persisted attachment configuration, network helper allocation request, returned metadata, hostname database, and container-facing network DNS listener; compare the draft implementation in #1815. Done means aliases resolve per network, duplicate names are rejected, and all names are released with the attachment.

Written by the indexing model from the issue text.