[Bug]: container exec does not join the container's IPC namespace (mount and PID namespaces are joined correctly)

### Description

A process started with `container exec` does not join the container's **IPC namespace**, although it correctly joins the mount and PID namespaces. Anything relying on System V shared memory therefore cannot see what PID 1 created, even though it is otherwise inside the container.

### Reproduction

```sh
container run -d --name ipccheck docker.io/library/alpine:latest sleep 90

container exec ipccheck sh -c '
echo "pid1 ipc=$(readlink /proc/1/ns/ipc) mnt=$(readlink /proc/1/ns/mnt) pid=$(readlink /proc/1/ns/pid)"
echo "exec ipc=$(readlink /proc/self/ns/ipc) mnt=$(readlink /proc/self/ns/mnt) pid=$(readlink /proc/self/ns/pid)"'
```

### Actual

```
pid1 ipc=ipc:[4026532181] mnt=mnt:[4026532179] pid=pid:[4026532182]
exec ipc=ipc:[4026531839] mnt=mnt:[4026532179] pid=pid:[4026532182]
```

`mnt` and `pid` match; `ipc` does not. `4026531839` is the host/initial IPC namespace.

### Expected

The exec'd process joins the container's IPC namespace, so `readlink /proc/self/ns/ipc` matches `/proc/1/ns/ipc` — consistent with the mount and PID namespaces, and with `docker exec` semantics.

### Impact

Any exec'd command that must reach PID 1's SysV shared memory fails. It surfaced with Oracle: the `gvenzl/oracle-free` image's own `healthcheck.sh` connects via `sqlplus -s /` (OS authentication, which attaches to the SGA in shared memory) and always fails with

```
ORA-01034: The Oracle instance is not available for use.
ORA-27101: shared memory realm does not exist
```

even while the database is up and serving TCP clients normally. Two consequences:

- **`docker exec … sqlplus` is unusable for ad-hoc inspection**, though connecting over TCP through the listener works, because the listener spawns the server process in PID 1's namespace.
- Under a Docker-API shim the image's healthcheck can never pass, so `depends_on: condition: service_healthy` never satisfies and `compose up` waits indefinitely. Substituting a TCP-based probe is a workaround, but it means stock images with exec-based healthchecks do not work unmodified.

The same would affect any exec'd tooling for PostgreSQL, DB2, or other software that attaches to a SysV shared-memory segment.

### Environment

| | |
|---|---|
| container | 1.2.2 (Homebrew) |
| macOS | 26.5.2 |
| Hardware | Apple silicon, arm64 |

Start by running the provided container run and container exec reproduction, comparing the IPC, mount, and PID namespace links. Trace the container exec namespace setup in the Swift implementation and verify that the exec'd process reports the same IPC namespace as PID 1, while the existing mount and PID behavior remains unchanged.

Written by the indexing model from the issue text.