refactor: consolidate command execution and reduce command logging exposure

[abtreece]

Problem

Command execution is shell-string based, logs the full command, and has a legacy helper that bypasses the newer timeout/cancellation path.

Verified in:

• pkg/template/command_executor.go:181-254, where runCommandWithTimeout executes commands via cmd /C on Windows or /bin/sh -c on Unix.
• pkg/template/command_executor.go:183, where the full command string is attached to the logger attributes.
• pkg/template/command_executor.go:215-220, where output is truncated but the command itself is not redacted.
• pkg/template/command_executor.go:259-276, where legacy runCommand executes shell commands without context, timeout, process-group cleanup, or structured metrics.
• runCommand appears to be referenced only by tests in pkg/template/resource_test.go.

Why this is a problem

Shell execution may be acceptable for operator-configured check_cmd and reload_cmd, but it keeps quoting and expansion semantics implicit. Logging the full command can expose secrets if operators put credentials or tokens in command strings.

The legacy runCommand helper is a second execution path that lacks the safety features added to commandExecutor, increasing maintenance cost and the chance of future code using the wrong helper.

Suggested refactor

• Remove runCommand or route it through commandExecutor test helpers.
• Consider redacting or omitting full command strings from info/error logs; keep them only at debug if needed.
• Document shell semantics clearly for configured commands.
• Consider supporting structured command args in a future config format while preserving shell-string compatibility.

Acceptance criteria

• There is one production command execution path.
• Command execution always uses context cancellation and configured timeouts.
• Logs avoid exposing full command strings at normal levels.
• Tests cover timeout, cancellation, exit status, and output truncation through the canonical executor.