Local deploy (--target local) uses a hardcoded, unnamespaced Compose project name ("stacker"), causing cross-project container/network/volume collisions

[vsilent]

Summary

stacker deploy --target local always uses the Docker Compose project name stacker (not derived from project.identity or name in stacker.yml). Deploying any project locally on a machine that has previously locally-deployed a different stacker project causes real collisions:

• Container names collide (stacker-app-1, stacker-postgres-1, ...) — deploying project B recreates/destroys project A's running local containers.
• Named volumes collide when two projects happen to use the same volume name (e.g. postgres_data → stacker_postgres_data) — project B's Postgres container mounts project A's already-initialized data directory, so POSTGRES_USER/POSTGRES_DB env vars are silently ignored (Postgres only runs init scripts on an empty data dir) and the app fails to authenticate against a database/role that was never created for it.
• docker compose ... down --remove-orphans on one project reports and removes other, unrelated projects' containers as "orphans" of the stacker project.

Steps to reproduce

1. cd stacker-projects/ntfy && stacker deploy --target local — succeeds, stacker-app-1 running ntfy.
2. cd ../shlink && stacker deploy --target local — output shows:

   Container stacker-app-1 Recreate
   Container stacker-app-1 Recreated
   

   This replaces ntfy's running container with shlink's, under the same name/project.
3. shlink's postgres service comes up using volume stacker_postgres_data. If any other project previously created a volume with that same generic name under the shared stacker project, the new Postgres container mounts pre-existing (differently-initialized) data:

   FATAL: password authentication failed for user "shlink"
   DETAIL: Role "shlink" does not exist.
   

   even though stacker.yml correctly sets POSTGRES_USER: shlink / POSTGRES_DB: shlink and the generated compose is correct — the volume just isn't empty, so Postgres skips its init scripts.
4. Running docker compose -p stacker -f .stacker/docker-compose.yml down --remove-orphans for the shlink project prints and removes containers belonging to entirely unrelated projects tested earlier in the same repo (e.g. stacker-socioboard-1, stacker-mastodon_db-1, stacker-gitea_db-1, stacker-mysql-1, stacker-redis-1, stacker-otel-collector-1).

Expected

Local deploys should be namespaced per project (e.g. Compose project name derived from project.identity/name, and/or volume names prefixed with the project identity) so that deploying one project locally never touches another project's local containers, networks, or volumes — the same way deploy --target cloud/--target server isolate projects by server/project id.

Impact

High — this repo intentionally exercises stacker deploy --target local across 100+ independent projects on the same dev machine (see trydirect/stacker-project-examples), and this bug means testing project B's local deploy can silently corrupt or destroy project A's local deploy state, with misleading downstream symptoms (e.g. "password authentication failed" that looks like a project config bug but is actually a volume-namespacing bug).

Environment

• stacker CLI 0.3.1 (fbffb9e)
• macOS, Docker Desktop
• Reproduced testing stacker-projects/ntfy followed by stacker-projects/shlink in trydirect/stacker-project-examples