Track future Base docker-service adoption in base-demo

[codeforester]

Context

Base issue basefoundry/base#124 tracks future docker-service artifact support: Base should orchestrate Docker Compose services without replacing Docker, Docker Compose, or project-owned Compose files. base-demo already has the representative substrate for that work: infra/compose.yaml, services/catalog.json, the Dockerized Go API, Compose-backed Postgres/MySQL/Redis, and the services lifecycle command.

When Base finalizes a docker-service manifest contract, base-demo should become the proving ground for that contract.

Scope

• Track the base-demo side of Base docker-service adoption.
• Wait for Implement future docker-service artifact support when a real project needs it base#124 to define the supported manifest shape and behavior.
• Decide which existing base-demo service should be represented through the Base-owned docker-service contract first. The likely first candidate is go-api or one infrastructure dependency.
• Preserve services/catalog.json and bin/base-demo-services as the project-owned operator surface unless Base intentionally supersedes part of it.
• Update README, docs/representative-environment.md, docs/contracts.md, demo walkthrough, and tests when the Base contract exists.

Validation

Validation will depend on the Base contract, but should include at minimum:

• ./tests/validate.sh
• git diff --check
• a Base command smoke test that proves the docker-service declaration is discovered or checked
• service dry-run behavior remains safe and does not require Docker to be running for baseline validation

Dependencies

Blocked on basefoundry/base#124 or another Base PR that lands the actual docker-service manifest contract.

Non-goals

• Do not invent a base-demo-only manifest shape.
• Do not require Docker for the default repository validation path until Base has a tested, opt-in contract.
• Do not turn base-demo into a broad local services platform; keep the representative environment compact and inspectable.