fix(operator): correct local kubeops CLI detection

[fuguiKz]

Addresses #1030.

Context

During dotnet publish, KubeOps runs kubeops generate ... via MSBuild targets. When the global kubeops command isn't available (common in Docker/CI), the targets try to detect a local tool fallback.

The local-tool probe currently uses dotnet tool run kubeops -h, but -h is parsed by dotnet tool run itself (help), so it can exit 0 even when there is no tool manifest / no local kubeops tool. This false-positive switches KubeOpsCli to dotnet tool run kubeops and then fails later during generation.

Change

• Probe the local tool via dotnet tool run kubeops -- -h so -h is forwarded to kubeops and the exit code reflects actual tool availability.
• Keep kubeops generate ... failures as errors (no ContinueOnError).

Tested

• Local: verified dotnet tool run kubeops -h vs dotnet tool run kubeops -- -h semantics and ran a minimal MSBuild repro.
• CI: GitHub Actions on this PR.

[kimpenhaus]

@fuguiKz thanks for the pr <3

this is just my personal flavour but I actually don't like a continue on error flag here. if the target is configured to run it should work proper - if it is not needed, it should be deactivated by configuration.

I wish to understand more of the details raised in issue #1030

thanks for your understanding

[fuguiKz]

@kimpenhaus thanks for the feedback!

Agree that making the actual kubeops generate ... step best-effort via ContinueOnError is the wrong direction, so I dropped that change.

Instead I dug into why #1030 is failing in Docker/CI and it looks like the local-tool detection is giving a false positive:

• The targets probe the local tool via dotnet tool run kubeops -h.
• But -h is handled by dotnet tool run itself, so it exits 0 and prints help even when there is no tool manifest / no kubeops tool.
• This makes the build switch KubeOpsCli to dotnet tool run kubeops, and then the later generate operator call fails with “Cannot find a tool in the manifest …”.

Fix in this PR: change the probe to dotnet tool run kubeops -- -h so -h is forwarded to kubeops and we get a real exit code (non-zero when the tool isn’t installed).

This should unblock Docker builds without masking real generation failures (when kubeops is actually available but returns a non-zero exit code).

[kimpenhaus]

@fuguiKz

But -h is handled by dotnet tool run itself, so it exits 0 and prints help even when there is no tool manifest / no kubeops tool.

good catch 👍🏼 that totally makes sense