fix(cli): keep --entrypoint a single token, matching Docker

[us]

Follow-up to #85, which landed the compose entrypoint: support (thanks @itxtoledo). That PR also changed the --entrypoint CLI flag on run, create and compose run to split its value on spaces and splice the extra tokens ahead of the command argv. This reverts that part; the compose fix stays.

Why

Docker does not split --entrypoint. docker/cli wraps the flag value in a single-element slice:

if copts.entrypoint != "" {
    entrypoint = []string{copts.entrypoint}
}

So in Docker, --entrypoint "/bin/sh -c" is one executable path and fails to launch. Splitting made mocker accept input Docker rejects, and broke an entrypoint path that legitimately contains a space (/opt/my app/run.sh was silently torn into two argv elements).

The Docker way of passing entrypoint arguments already works and is unchanged:

mocker run --entrypoint /bin/sh alpine -c "echo hi"

Changes

• Run.swift, Create.swift, Compose.swift (compose run): pass --entrypoint through untouched. Pure deletion, 3 files, -30/+6.
• Compose service entrypoint: is unaffected. It is a real list and still resolves through ComposeOrchestrator.resolveExec, which keeps the Docker ENTRYPOINT + CMD concatenation within Apple container's single-token --entrypoint constraint.

Verification

swift build clean, swift test 454 tests pass.

Against the real runtime:

• mocker run --entrypoint /bin/sh alpine -c "echo DOCKER_FORM_OK" -> DOCKER_FORM_OK
• mocker run --entrypoint "/bin/echo hi" alpine -> failed to find target executable /bin/echo hi (same as Docker; previously it silently succeeded)
• mocker compose up -d with entrypoint: ["/bin/sh", "-c"] + command: -> container up, logs show the expected output

Compatibility

No behavior that worked before #85 changes. The only thing removed is the space-splitting introduced by #85, which is not in any release yet.

[itxtoledo]

thanks