http/codegen: wrap cli.ParseEndpoint error in generated CLI

[stakahashy]

Summary

• wrap the cli.ParseEndpoint return value in http/codegen/templates/cli_end.go.tpl with fmt.Errorf("parse endpoint: %w", err) so the generated example CLI passes golangci-lint with wrapcheck enabled
• update the affected client golden files under http/codegen/testdata/golden/

Today the generated cmd/<svc>-cli/main.go does return cli.ParseEndpoint(...), which returns an error from another package without wrapping it. wrapcheck flags this on every fresh goa example output and downstream projects have to either disable the linter or post-process the generated file.

"fmt" is already in the import spec list in http/codegen/example_cli.go, so no additional source change is needed; goimports retains it now that the template references fmt.Errorf.

Follows the spirit of #3541 / #3542 / #3548 / #3736 / #3927 (golangci-lint cleanup on generated code).

Test plan

• go test ./http/codegen/...
• make test
• make lint

[raphael]

Thanks for cleaning this up, this is a nice little quality-of-life fix for generated CLIs.

One thing I think this changes accidentally: the example client has an HTTP -> JSON-RPC fallback in client_endpoint_init.go.tpl that checks whether the HTTP parse error starts with unknown. After this wrap, the error string starts with parse endpoint:, so JSON-RPC-only commands on shared http/https schemes won't fall through anymore.

I think either the fallback needs to unwrap/check the underlying error, or this template should preserve the existing unknown... prefix for that specific path. Also worth checking the gRPC example CLI template too, since it still returns cli.ParseEndpoint(...) directly if the goal is wrapcheck-clean generated CLIs across transports.

[raphael]

Perfect, thank you!