Fix relative path resolution in entrypoint

[ParkSeongGeun]

• Fixes [Bug]: relative path in 'entrypoint' is not accepted #962

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Motivation and Context

• When using a relative path in --entrypoint (e.g., ./rustc), the container fails with "failed to find target executable". This change resolves relative paths against the working directory, matching the behavior of Docker and Podman.
• Changes in Relative Path Resolution: Updated the parser to detect if the entrypoint or command starts with a relative path and automatically resolve it using the workingDir.
• Changes in Path Normalization: Integrated URL.standardized.path to ensure that paths containing ./ or ../ are converted into clean, absolute strings before being passed to the runtime.

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

Verification Scenarios

Verified the fix on macOS 26.0 (Target: arm64-apple-macosx26.0) with the following integration tests:

1. Relative path with ./: container run --rm --workdir /bin --entrypoint ./ls alpine
   • Result: Resolved to /bin/ls and executed successfully.
2. Relative path without prefix: container run --rm --entrypoint bin/ls alpine
   • Result: Resolved to /bin/ls (combined with default root /) and executed successfully.
3. Absolute path (Regression): container run --rm --entrypoint /bin/ls alpine
   • Result: Remained unchanged and worked as expected.
4. Path Normalization: Verified that complex paths like ../bin/ls are standardized correctly via URL.standardized.

Unit Tests

Ran swift test --filter ProcessEntrypoint to confirm all logic cases in ParserTest.swift pass.