[fix] deploy rebuilds a project's own image

[malickyeu]

Summary

This started as the roadmap item "upload build: contexts to a remote host". It
ends somewhere else, so the short version first:

The roadmap item was based on a wrong premise, and building it would have been
wasted work. Docker's build API takes the build context as a tar stream from
the client, so a remote daemon has always received your local ./app folder and
built the image there. Verified before writing any code: the image ends up only on
the remote daemon and contains a file that exists only in the local context.

That is genuinely different from a bind mount — which nothing uploads, and which is
precisely why the dcseed-* volume seeding exists. Conflating the two is what put
the item on the roadmap. It's now retired in NEXT.md with the reasoning, so it
doesn't come back.

What the investigation did find is a real bug, and it's the fix here.
docker compose up -d builds a service only when its image is missing. So a
project with a build: section was built on its first deploy and never again:
every later deploy reused the original image no matter what changed in the
Dockerfile or its context. Edit a Dockerfile in the project editor, hit Deploy, and
the CLI reports Container Running and exits 0 — a wrong answer delivered as a
success, which is the worst shape for a bug in a tool whose whole promise is "the
files in the editor are what runs."

Deploy now passes --build.

Type of change

• Bug fix
• New feature
• Docs only
• Refactor / chore

Checklist

• go test -short ./... and go vet ./... pass
• gofmt gate is clean (gofmt -l $(git ls-files '*.go') after staging)
• Frontend type-checks (cd web && npx tsc --noEmit)
• Rebuilt and committed web/dist
• Added/updated tests for the change
• Updated docs/ and added a CHANGELOG.md entry

Notes for reviewers

Why --build unconditionally rather than a toggle. It is a no-op for services
that only pull an image, so the cost lands exactly where the benefit is: on
projects that actually declare build:, which are precisely the ones that were
silently going stale. That avoids a UI toggle nobody would find before being bitten
once. POST with {"build": false} opts out for the rare case where re-sending a
large context over a slow link matters more than freshness — the request field is a
*bool so absent means rebuild, and false is distinguishable from unset.

MCP matches the UI (mcpDeployProject passes true). Not a widening of the
MCP surface: up already builds a missing image, so deploying a project with a
build: section could always run its Dockerfile. What it fixes is the
inconsistency where the same project deployed via MCP would keep a stale image
while the UI refreshed it.

Two tests, and both were checked against the bug rather than assumed:

• TestIntegrationComposeUpRebuildsChangedContext pins both halves — that
  without --build a context change is ignored, and with it the change lands.
  The negative half is the point: a test asserting only "the new content appears"
  would pass for the wrong reason if compose ever rebuilt incidentally, and would
  never have caught the original bug.

• TestRemoteBuildContextDeployEndToEnd (gated on DC_REMOTE_DOCKER) covers the
  combination nothing else reached: a project that builds its own image and
  bind-mounts a project file, deployed to a daemon that can't see the folder.
  The two mechanisms travel completely differently and meet in one
  -f compose.yml -f override.json invocation. It also asserts the build context
  is not misclassified as a bind needing seeding.

  Verified by mutation: flipping that deploy to build=false fails it with
  /marker.txt = "BUILT-V1" after the edit. Run against a docker:28-dind
  sidecar at tcp://127.0.0.1:12500.

Also corrected a UI string that had become false. The remote-host hint still
said bind-mounting projects were "blocked at deploy … until file sync lands" —
seeding shipped a while ago. It now describes what actually happens, including that
build: contexts are uploaded with the build.

Test data: all containers/images created during verification were removed; the
dind sidecar is torn down separately.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.