Fix/compose build detection

[amaan14999]

Change Summary

Fixes #4963.

Deploying an app configured with [build.compose] was broken in two ways:

1. If a Dockerfile happened to be present, fly deploy built that and ignored the compose file entirely.
2. If there was no Dockerfile, the deploy failed with app does not have a Dockerfile or buildpacks configured - even when every compose service just referenced a pre-built image and needed no build at all.

What and Why:

On every deploy, flyctl runs a single "build one image from source" step. That step only ever looked at the top-level [build] config and, failing that, auto-detected a Dockerfile in the working directory. It never read the compose file. So the "should we build, and from what?" decision and the compose file's build: directive were completely disconnected - the build step didn't know compose existed.

(For contrast, the machine-config-JSON path always designates exactly one container to build, so it always needs a Dockerfile. Compose is different: it may have one buildable service, or none at all. The old code treated both paths the same.)

How:

Connect the two. The deploy now reads the compose file to decide what to do:

• No service has a build: section → nothing to build. Skip the source build and deploy each container with its own image. No more spurious Dockerfile builds, and no more "does not have a Dockerfile" error.
• A service has a build: section → build from that section's context and dockerfile, instead of guessing at a root Dockerfile.

Both the shorthand (build: ./dir) and long(build: { context:, dockerfile: }) compose forms are supported.

Related to:

---

Documentation

• Fresh Produce
• In superfly/docs, or asked for help from docs team
• n/a

[vcollab-kishan]

Will this be available for next official release? Seems to be the blocker now.