feat(telemetry): integrate Datadog Installer lightweight tracer

[julesmcrt]

See example trace (from a local run)

Summary

• Emit spans for rshell execution via the Datadog Installer's lightweight tracer (pkg/fleet/installer/telemetry), so embedders like PAR can observe restricted-shell runs without wiring a full tracer themselves.
• Span layout (operation → resource):
  • run → run: Runner.Run envelope, tagged with rshell.version
  • command → : each dispatched command, with name, argc, exit_code, is_allowed, is_known, has_stdin_pipe, has_output_redirect tags
  • control_flow → if | for | for.iteration | pipeline: flattened grouping spans with structural tags (branch_count/branch_taken, iteration_count/broke_early/variable_name, stage_count/exit_code)

Two telemetry paths

• Embedded in datadog-agent (PAR — the path customers hit): rshell itself never constructs a `*Telemetry` and never opens an HTTP connection. PAR constructs the sender once at startup with its own proxy-aware `*http.Client`, and rshell's spans register on the installer tracer's package-global span registry — they flush through PAR's sender. No HTTP wiring ships in the rshell library.
• Standalone rshell binary (local use only): ships with telemetry off by default. Build with `-tags with_telemetry` and set `DD_API_KEY` (+ optional `DD_SITE`) to flush to intake. In that build, `cmd/rshell/telemetry_on.go` constructs a `*Telemetry` using `http.DefaultClient` (so `HTTP_PROXY` / `HTTPS_PROXY` are honored) and flushes on exit. This path is strictly for running rshell directly from a terminal — it is never used when rshell is invoked through the datadog-agent.

Why no arg sanitization on `rshell.command.name`

By the time `call()` runs, the shell parser (`mvdan.cc/sh/v3`) has already lexed, expanded, and quote-stripped the input; `args[0]` is a valid command word — a builtin name, a path like `./script.sh`, or a variable-expanded result in command position. Realistically it's never a secret (a customer executing a password as a command is not a failure mode worth engineering around). Metric cardinality is the only residual concern and is bounded in practice.

Test plan

• `go test ./...`
• `RSHELL_BASH_TEST=1 go test ./tests/ -run TestShellScenariosAgainstBash` (byte-for-byte bash parity, including 5 new scenarios stressing the iterative `execIfChain` walk)
• Local end-to-end (standalone path only — not exercised via PAR): `go build -tags with_telemetry -o /tmp/rshell ./cmd/rshell` → `DD_API_KEY="XXX" /tmp/rshell --allow-all-commands -c 'for x in apple banana cherry; do if [ "$x" = banana ]; then echo hi | cat | grep hi; elif [ "$x" = apple ]; then echo elif-branch; true; else echo else-branch; false; fi; done; false || true'` → traces visible under `service:rshell`

🤖 Generated with Claude Code

[astuyve]

FYI including the telemetry package here uses the agent telemetry instead of http client, which is initialized in telemetry_on.go only when the build tag is applied and in a local/test build context.