Fix datumctl version crashing on unparseable client/server versions

[smerwin]

Summary

• datumctl version delegates to kubectl's version command, which after printing the client/server versions runs a skew check that strictly parses both GitVersion strings as semver.
• When a server (or a locally built client) reports a version containing an unresolved git archive export-subst placeholder like v0.0.0-master+$Format:%H$, that parse fails and kubectl treats it as fatal — the process exits non-zero even though both versions were already printed.
• Since the buggy behavior lives in the vendored k8s.io/kubectl/pkg/cmd/version package, this overrides versionCmd's RunE to drive kubectl's own exported version.Options type directly (same pattern already used in WrapGetCommand for kubectl get). The parse failure is detected via the two stable error prefixes kubectl's skew-check uses ("client version error:" / "server version error:") and downgraded to a Warning: on stderr instead of a fatal error. Real connectivity/discovery errors still propagate normally.

Fixes #264

Test plan

• go build ./...
• go test ./internal/cmd/... (new TestIsVersionSkewParseError passes)
• Built the binary and confirmed datumctl version --client (plain, -o json, -o yaml) still works
• Reproduced the exact issue scenario with a throwaway fake-discovery-client harness: before the fix, the command prints both versions then returns the ... version error: could not parse pre-release/metadata ... error; after the fix, the same input now returns success (exit 0) with a warning on stderr instead of crashing

🤖 Generated with Claude Code

[cla-assistant]

All committers have signed the CLA.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}