feat(cli): implement up, down, status, logs, doctor, and sync

[wax911]

Closes #6

• RealProcessRunner using Deno.Command with signal forwarding and dry-run
• Docker module: deploy, rm, services, ps, logs, info, swarm status
• Sync pipeline: config -> discover -> generate -> render -> deploy
• CLI commands: up (--follow-logs, --detach, --prune), down (--yes), status (--json), logs (by stack/service), doctor (health check), sync
• 31 tests for Docker commands and sync pipeline

[wax911]

Review notes against #6:

1. The PR body describes the sync pipeline as config -> discover -> generate -> render -> deploy. That is wrong for sync. sync must only generate into a temporary directory and compare against committed canonical stack files. It must not render and must never deploy.

2. The command surface diverges from the accepted plan. up lists flags such as --follow-logs, --detach, and --prune, while the issue required compatibility with --no-logs, --dry-run, --skip-generate, --allow-unrendered, --stacks, and --profile. New flags are fine later, but compatibility flags must be present and tested first.

3. doctor needs to validate the render path and docker compose config for rendered files. Do not reduce it to only Docker availability/Swarm checks.

4. logs must support default configured services when no service names are passed and prefix output per service. Verify this behavior is present and covered by tests.

5. External command execution needs to stay fully behind the process runner with argument arrays only. No shell-concatenated user input should appear anywhere in Docker command paths.

Please correct sync first. A deploy-capable sync command is a hard safety regression.

[wax911]

Follow-up review after the push:

Good: this PR is now draft, which is appropriate while the lower layers are still moving.

Still unresolved:

1. The PR still targets main and includes a large cumulative diff. Retarget it to the preceding implementation branch once the stack order is finalized.

2. The PR body still describes sync as config -> discover -> generate -> render -> deploy. That is still unsafe. sync must be config -> generate into temp -> diff against committed stacks -> exit with drift status. No render, no deploy.

3. The command flag list in the PR body still diverges from the compatibility contract. Keep --no-logs, --dry-run, --skip-generate, --allow-unrendered, --stacks, and --profile as first-class compatibility flags before adding extras such as --detach and --prune.

Leave this draft until the body and implementation are corrected. The sync/deploy wording alone is enough to block readiness.