fix(build): hand unresolved 'auto' progress mode to bake

[ndeloof]

display.Mode resolves auto against stderr — the stream Compose's own progress renders to — so compose build >/dev/null in an interactive terminal resolves to tty. Bake reuses that mode for a display writing to stdout, and buildkit's progressui hard-fails in tty mode when the stream is not a console.

Pass the unresolved auto to bake unless the user explicitly asked for tty: progressui then probes the actual output stream and degrades to plain by itself when stdout is redirected. An explicit --progress=tty keeps failing loudly on a non-terminal, matching buildx bake. This also revives the BUILDKIT_PROGRESS override in doBuildBake, which only applies to auto mode and could no longer trigger.

Alternative to #14184, addressing the root cause upstream of build_bake.

Fixes #14182

🤖 Generated with Claude Code

[docker-agent]

Assessment: 🟢 APPROVE

The fix is correct and well-targeted. display.Mode is resolved against stderr by selectEventProcessor; by passing the unresolved auto back to bake when tty was auto-selected (not user-forced), buildkit's progressui probes the actual stdout stream independently — fixing the hard-fail when stdout is redirected. Explicit --progress=tty is preserved and still fails loudly on a non-terminal, consistent with buildx bake.

The new test correctly exercises all the relevant cases: auto→tty→auto round-trip, explicit tty pass-through, plain/quiet/json pass-through, and json→rawjson mapping. The global-mutation-plus-Cleanup pattern matches the pre-existing convention in compose_progress_test.go.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!