feat: add exec command for interactive container terminal access

Summary

Add an exec command that allows users to open interactive terminal sessions in running Dokploy containers directly from the CLI — similar to heroku run.

Motivation

Currently, the only way to get terminal access to a running container is through the Dokploy web panel's Terminal tab. There's no CLI equivalent, which makes it difficult to:

• Run one-off commands like rails c, python manage.py shell, or database migrations
• Integrate with local development workflows and scripts
• Provide quick terminal access without opening a browser

This is a commonly expected feature for PaaS CLI tools (Heroku, Fly.io, Railway all support it).

Proposed solution

A new hand-authored command (src/commands/exec.ts) that:

1. Resolves the service name to a running container via the existing Dokploy API (project.all → application.one → docker.getContainersByAppLabel)
2. Connects via WebSocket to the /docker-container-terminal endpoint (the same protocol the web panel uses)
3. Pipes raw stdin/stdout for an interactive terminal session

Usage

# Interactive shell
dokploy exec --app Web

# Run a command
dokploy exec --app Web rails c

# Disambiguate across projects/environments
dokploy exec --project "My Project" --env staging --app Web rails c

Supported service types

Works with all Dokploy service types: applications, redis, postgres, mongo, mysql, mariadb, and compose.

Authentication

Uses the existing x-api-key authentication — no SSH access to the server required. Teammates only need a Dokploy API key.

Implementation

I have a working implementation ready to submit as a PR. It adds:

• src/commands/exec.ts — the new command
• ws dependency — for WebSocket client
• Updated README with usage docs

Happy to adjust the implementation based on feedback.

Start by reading the existing CLI command structure and the API flow named in the issue: project.all, application.one, and docker.getContainersByAppLabel. Review src/commands/exec.ts and the README changes, then verify the documented interactive and command modes across the listed service types. Done means the command resolves the intended running container, maintains terminal input/output, authenticates with x-api-key, and is documented.