Support repo-local config for context selection

Problem

The CLI currently stores contexts globally in ~/.config/coolify/config.json, which works well for personal defaults but is awkward for repository-specific workflows.

When working across multiple repos, teams, or customer environments, it is easy to accidentally run commands against the wrong Coolify context unless the operator remembers to pass --context every time or changes the global default back and forth.

That creates avoidable risk for commands like deploys, deletes, restarts, env syncs, and other mutations.

Proposal

Support a repo-local config file that the CLI can discover from the current working directory upward.

Possible shapes:

• .coolifyrc
• .coolify.toml
• .coolify/config.json

A minimal first version could support only the context name, for example:

context = "production"

or:

{
  "context": "production"
}

Then the CLI could resolve config with a precedence like:

1. Explicit flags (--context, --host, --token)
2. Repo-local config
3. Global config default

Why this would help

• Makes repo-specific automation safer
• Reduces accidental deploys to the wrong instance
• Avoids constantly switching the global default context
• Gives teams a shareable, documented convention for which Coolify context belongs to a repo
• Keeps credentials global while allowing repo-local intent

Notes

I am not suggesting storing tokens in the repo. The repo-local file could just point to a named context that already exists in the user's global config.

That would keep secrets in the existing global config while making per-repo targeting much clearer.

Start by tracing how the CLI loads ~/.config/coolify/config.json and resolves --context, --host, and --token. Decide the supported repo-local format and upward discovery behavior before implementing precedence over the global default. Done means repository context selection is reliable without storing tokens locally, with coverage for explicit flags, repo-local configuration, and global fallback.