FEATURE_REQUEST: services[].profiles in stacker.yml schema (compose profiles passthrough) #300

Summary

stacker.yml's services: schema has no profiles field, so profile gating
is lost when Stacker generates .stacker/docker-compose.yml. Services that
upstream compose treats as optional variants (e.g. GPU builds) always end up
in the generated compose and are always started — which breaks deploys on
hosts where those variants cannot run.

Background

Docker Compose profiles mark services as opt-in:

services:
  ollama-cpu:            # no profiles -> starts by default
    image: ollama/ollama:0.40.4
  ollama-gpu-amd:
    image: ollama/ollama:0.40.4-rocm
    profiles: [gpu-amd]  # started only with COMPOSE_PROFILES=gpu-amd
    devices: [/dev/kfd, /dev/dri]

Upstream coleam00/local-ai-packaged uses exactly this to ship three Ollama
variants (cpu / gpu-nvidia / gpu-amd) in one compose file.

Motivating failure

Deploying the local-ai-packaged stack to a CPU-only host aborts the whole
docker compose up:

Error response from daemon: error gathering device information while adding
custom device "/dev/kfd": no such file or directory

One service (ollama-gpu-amd) failing on a missing device kills the entire
compose up — half the containers stay Created, the deployment is marked
paused [local_exec_provisioner_error] (cloud path) or paused [internal_error] (server path). Seen in deployments #1382, #1383, #1385
(2026-10-16 / 2026-10-19). COMPOSE_PROFILES= in .env cannot help because
the generated compose contains no profiles: keys to activate.

Proposal

Add profiles to the stacker.yml service schema and pass it through:

1. ServiceDefinition (src/cli/config_parser.rs): pub profiles: Vec<String>
   (default empty).
2. ComposeService (src/cli/generator/compose.rs): emit profiles: when
   non-empty (same pattern as cap_add / devices).
3. Validate & tests: accepted by stacker config validate; generator test
   asserting the emitted compose block; omitted field behaves exactly as
   today.

Example:

services:
  - name: ollama-gpu-amd
    image: ollama/ollama:0.40.4-rocm
    profiles: ["gpu-amd"]
    devices: ["/dev/kfd", "/dev/dri"]

Related gap (same class)

ComposeService already has user (and shm_size) but ServiceDefinition
cannot express them, so services[].user: root (e.g. the surrealdb volume
ownership workaround in open-notebook) is likewise impossible from
stacker.yml. Worth adding in the same pass.

Workarounds today

None inside the schema. Templates must either drop optional variants
(feature loss) or replace devices: with privileged: true (broader device
access than intended).