Fix Go install

[stephanos]

What was changed

Removed cliext's go.mod.

Why?

Currently this fails:

go install github.com/temporalio/cli/cmd/temporal@main

go: downloading github.com/temporalio/cli v1.5.2-0.20260112210410-f2d230be226c
go: github.com/temporalio/cli/cmd/temporal@main (in github.com/temporalio/cli@v1.5.2-0.20260112210410-f2d230be226c):
	The go.mod file for the module providing named packages contains one or
	more replace directives. It must not contain directives that would cause
	it to be interpreted differently than if it were the main module.

With this change, it works again:

go install github.com/temporalio/cli/cmd/temporal@fix-install
go install github.com/temporalio/cli/cmd/gen-commands@fix-install

The downside of this approach is that consumers of cliext have to download more dependencies.

Checklist

1. Closes

2. How was this tested:

3. Any docs updates needed?

[cretz]

Go install for internal users is much less important than our public users' ability to consume this library. Also, if this were like v0.1.0 and we had a tag of cliext/v0.1.0 this wouldn't be a problem until we made changes we dogfooded I guess.

I don't mind if we are now saying the cliext library will be versioned the same as the CLI, I just want to make sure we're doing it for the right reasons and not because go install doesn't work because it has never been tagged.

Can you help me understand the reasons we added go.mod in the first place? The extension proposal at https://github.com/temporalio/proposals/blob/master/cli/cli-extensions.md#helper-library has:

The CLI module is versioned the same as the CLI binary version. The version of CLI used by users can be different than the version of CLI module used by extensions, but there may be issues if the CLI version used by a user is newer than the one used by an extension mostly due to new flags and Temporal client capabilities. Within reason, the CLI team will try to maintain runtime behavior compatibility with extensions using older forms of this library.

But I could totally see us deciding otherwise post-proposal, I just forget what we had discussed.

[stephanos]

Honestly, I think it was just me trying to be clever and reducing the dependencies for cliext consumers. Effectively with this change, there will be more to download - but the resulting binary shouldn't be affected at all. That's the only downside I can see.

[cretz]

Ah, that was it, I actually think this is fairly important. Requiring users of cliext to depend on the entire server repository is too much. Even if Go can reasonably elide some things in the binary, it is a huge build burden on library users IIUC. That is way worse than the inability to go install the CLI IMO (which is not a supported CLI installation method and shouldn't be used I don't think).