Deploy targets in config: `.miren/deploy.toml`

Problem

Deploying an app to the right cluster requires manually managing "active cluster" state via miren cluster switch. This is error-prone and tedious, especially for apps that target multiple clusters (e.g., staging + prod). There's no declarative way to say "this app deploys here."

Today's workflow:

miren cluster switch staging
miren deploy
miren cluster switch prod
miren deploy

Each step requires remembering which cluster you're targeting, and nothing in the repo captures that knowledge. New team members, CI pipelines, and AI agents all have to be told separately.

Proposal

Introduce .miren/deploy.toml — a new config file that captures where an app goes, complementing app.toml which captures what it is.

Rough shape:

[[targets]]
name = "staging"
cluster = "miren-staging"

[[targets]]
name = "prod"
cluster = "miren-prod"

Then:

miren deploy                  # deploys to default target (or prompts if ambiguous)
miren deploy --target staging # deploys to staging
miren deploy --target prod    # deploys to prod

Design questions (RFD territory)

• Default target semantics: first in list? explicit default = true? require --target when multiple exist?
• Per-target config overrides: should targets be able to override env vars, concurrency, etc.? (e.g., staging runs 1 instance, prod runs 10) — or is that a separate mechanism?
• Relationship to app.toml: deploy.toml is purely about targeting and deployment workflow; app.toml remains the app's structural definition. Where's the line?
• CI/CD integration: how does mirendev/actions/deploy consume this? --target flag?
• Multi-app repos: does deploy.toml live per-app (in .miren/) or can it define targets for multiple apps?
• Git-ignored secrets: if per-target env overrides exist, how do we handle secrets that shouldn't be in the repo?

Scope

This issue captures the concept. Design should be fleshed out in an RFD before implementation.