cmd/docker: print command error before running plugin hooks

[olabie2]

Plugin hook output (such as Gordon's "What's next:" hint) was rendered before the command's own error message because hooks were invoked inside runDocker while the error was only printed in main() after runDocker returned.

Print the error to stderr before invoking the hooks, and replace the error with a status-only cli.StatusError so main() does not print the same message a second time. The original error message is captured up-front and still passed to the plugin hooks.

Closes #6973

- What I did

Fixed the rendering order in cmd/docker/docker.go so that plugin hook output (for example, the ai plugin's "What's next: Debug this container error with Gordon …" hint) is printed after the command's own error output instead of before it.

- How I did it

In runDocker, the flow used to be:

1. cmd.ExecuteContext(ctx) returned an err.
2. Plugin hooks were invoked, writing "\nWhat's next:\n …" to dockerCli.Err().
3. runDocker returned err to main(), which then wrote the error message to os.Stderr.

So the actual stderr order was: hook output → error message.

The fix:

• Captures the original error message via cmdErrorMessage(err) into a local errMessage before mutating err.
• Prints err to dockerCli.Err() immediately after cmd.ExecuteContext, gated on the same conditions main() uses (!errdefs.IsCanceled, not errCtxSignalTerminated, non-empty err.Error()), so behaviour for cancellation, signal termination, and exit-code-only errors is unchanged.
• Replaces err with cli.StatusError{StatusCode: getExitCode(err)} (preserving the exit code) so main() does not print the same message a second time.
• Passes the captured errMessage to RunCLICommandHooks, so plugin hooks still receive the real error text rather than a synthetic "exited with code N" derived from the replaced error.

- How to verify it

With hooks enabled (features.hooks: "true" in ~/.docker/config.json or DOCKER_CLI_HOOKS=true) and a plugin registering an error-hooks entry for run (Docker Desktop provides this via the ai plugin):

docker run --rm --env-file=./no-such-file alpine

Before this change:

What's next:
    Debug this container error with Gordon → docker ai "help me fix this container error"
docker: open ./no-such-file: no such file or directory

Run 'docker run --help' for more information

After this change:

docker: open ./no-such-file: no such file or directory

Run 'docker run --help' for more information

What's next:
    Debug this container error with Gordon → docker ai "help me fix this container error"

Exit code is preserved (125 in this example). All existing tests in ./cmd/docker/... and ./cli-plugins/... still pass.

- Human readable description for the release notes

Print plugin hook output (e.g. the "What's next:" hint) after the command's error message instead of before it

- A picture of a cute animal (not mandatory but encouraged)

🐳

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
cmd/docker/docker.go	0.00%	5 Missing ⚠️

📢 Thoughts on this report? Let us know!

[vvoland]

Could you please add some tests for this?

I'd need to take a deeper look into it.

[vvoland]

Moved to 29.5.1 for now

[olabie2]

Sure I will add some later

[olabie2]

I added TestPrintCommandError covering every branch of the new behavior nil, generic error, StatusError with and without message, context.Canceled (raw + wrapped via %w), and errCtxSignalTerminated. To make this directly unit testable, I moved the inline logic from runDocker into a dedicated printCommandError helper, keeping it consistent with the existing getExitCode and cmdErrorMessage helpers.

I also verified locally with go test ./cmd/docker/..., golangci-lint run ./cmd/docker/..., and end to end against the original repro from #6973: error now prints before the What's next: hint, exit code 125 preserved. The same fix also works for unrelated failures (e.g. --bogus-flag), and the cancellation path (single Ctrl+C on a long-running docker run) still produces no unexpected output.

@vvoland