Record proxied exit codes and subcommands in command telemetry

[gtsiolis]

Motivation

exit status 252 recently became the top-ranked lstk error in analytics, but the telemetry behind that ranking flattens every command failure to exit_code=1 with the raw error string as the only signal, and records nothing about which proxied invocation failed. That makes questions like "what is driving the 252s" unanswerable (see the triage on the ticket).

Changes

• Record the real exit code in lstk_command telemetry: the new cmd.ExitCode helper maps a proxied tool's *exec.ExitError and the --json convention's output.ExitCodeError to their exact codes, and is now shared by main.go, instrumentCommands, and dispatchExtension, so the recorded exit_code always matches the process exit code
• Record a new parameters.subcommand field for the proxy commands (aws, az, terraform, cdk, sam): the leading service/operation tokens of the wrapped invocation (e.g. s3 ls). Collection stops at the first flag-like arg and is capped at two tokens of 64 runes, so flag values and free-form input are never recorded
• Process exit codes are unchanged; main.go now derives them from the shared helper

Tests

• Unit tests for cmd.ExitCode and proxySubcommand (flag-value safety, token cap, truncation, lstk global-flag stripping)
• Telemetry payload tests for the subcommand field (present for proxies, omitted when empty)
• Integration test running lstk aws s3 lss against a fake aws exiting 252: asserts the process exits 252 and the telemetry event carries command=aws, subcommand="s3 lss", exit_code=252 (verified failing before the change, passing after)

Towards DEVX-1003