up --wait does not imply detached mode and remains attached indefinitely

**Describe the bug**

`podman-compose up --wait` does not imply detached mode, despite its help text stating:

```text
--wait Wait for services to be running|healthy. Implies detached mode.
```

With a healthy, long-running service, `podman-compose up --wait` remains attached to the container and does not return. Adding `-d` makes the command behave correctly.

Docker Compose accepts `docker compose up --wait`, waits for the services to become running or healthy, and then returns because `--wait` implies detached mode.

**To Reproduce**

Create a directory for the reproducer:

```sh
mkdir -p /tmp/podman-compose-wait-repro
cd /tmp/podman-compose-wait-repro
```

Create `compose.yaml`:

```yaml
services:
app:
image: busybox:latest
command: ["sh", "-c", "sleep 3600"]
healthcheck:
test: ["CMD-SHELL", "true"]
interval: 1s
timeout: 1s
retries: 3
```

The commands below explicitly use `wait-repro` as the Compose project name.

Run `up --wait` without `-d`:

```sh
timeout 10s podman-compose -p wait-repro \
up --wait --wait-timeout 3

printf 'exit status: %s\n' "$?"
```

The command does not return after the service becomes healthy and is eventually terminated by the external timeout:

```text
exit status: 124
```

Clean up:

```sh
podman-compose -p wait-repro down
```

As a control, run the same command with `-d`:

```sh
podman-compose -p wait-repro \
up -d --wait --wait-timeout 3

printf 'exit status: %s\n' "$?"
```

This returns normally:

```text
exit status: 0
```

Clean up again:

```sh
podman-compose -p wait-repro down
```

**Expected behavior**

`podman-compose up --wait` should implicitly enable detached mode, wait until the service is running or healthy, and then return status `0` while leaving the container running.

It should behave equivalently to:

```sh
podman-compose up -d --wait
```

This matches both the `podman-compose --help` description and Docker Compose behavior.

**Actual behavior**

Without an explicit `-d`, `podman-compose up --wait` starts the service in attached mode and waits for the long-running container process to exit.

**Output**

```text
$ podman-compose version
podman-compose version 1.6.0

$ podman --version
podman version 4.9.3
```

**Environment:**

- OS: Ubuntu 24.04
- Podman: 4.9.3, rootless
- podman-compose: 1.6.0

**Additional context**

The `--wait` option is documented as implying detached mode:

https://github.com/containers/podman-compose/blob/v1.6.0/podman_compose.py#L4518-L4529

However, `compose_up` enters the detached code path only when `args.detach` is true. The readiness wait is also called only within that branch:

https://github.com/containers/podman-compose/blob/v1.6.0/podman_compose.py#L3549-L3564

Otherwise, execution proceeds to the attached code path:

https://github.com/containers/podman-compose/blob/v1.6.0/podman_compose.py#L3566-L3655

A possible fix would be to make `--wait` set or imply `args.detach`, while applying the same option compatibility checks as an explicit `--detach`.

Start in podman_compose.py around the option definition at lines 4518-4529, then trace compose_up through the detached and attached branches around lines 3549-3655. Reproduce the behavior with the provided compose.yaml and verify that up --wait waits for readiness, returns successfully, and leaves the service running without requiring -d.

Written by the indexing model from the issue text.