fix(up): drop unsupported network aliases instead of failing startup

[Cyb3rDudu]

Fixes #130.

Problem

Since #119, every service attached to a custom network fails to start on Apple Container 1.x:

Error: unknown network property 'alias'. Available properties: mac, mtu

container run only accepts the mac and mtu network properties.

Root cause

supportsNetworkAliases() probed container-compose's own ArgumentParser model (Application.ContainerRun.parse), which accepts any key=value — so it always reported true. networkRunArg then emitted alias=<service> unconditionally (even with no user-defined aliases), which the daemon rejects.

Verified directly against the daemon:

• container run --network "appnet,alias=web" → exit 1 (error above)
• container run --network appnet → works

Fix

• Replace the probe with an honest false — no Apple Container version supports aliases today.
• Only emit the warning when the user explicitly declared aliases; the implicit service-name alias is covered by the /etc/hosts fallback (feat(up): use Apple container DNS when domain registered, /etc/hosts fallback otherwise #97), so warning about it on every networked service was noise.

Verification

Smoke-tested a 2-service compose (service with aliases: [webby, frontend] on a custom network):

• Before: web failed to start with the alias error.
• After: both services start; warning fires only for the service with user aliases; ping web still resolves via /etc/hosts.
• Unit tests updated (networkAliasesWarnWhenUnsupported) + new networkAliasesNoWarningWithoutUserAliases; existing networkAliasesDoNotDuplicateServiceName still green.