fix(cli): stop reporting expected channel currentBundle failures as exceptions

[posthog-eu]

Summary

Problem

• The team was paged with a brand-new error tracking issue every time channel currentBundle ran against a channel name we hadn't seen before — even though nothing was broken.
• A channel that exists but has no bundle linked is a legitimate user-facing state: the CLI prints a clear message and exits 1. It is not a crash.
• Two things turned that into exception noise:
  • The global catch in cli/src/index.ts captured every non-Commander throw as a $exception; shouldCapturePosthogException only filtered commander.* codes.
  • The channel name was interpolated into the error message, so error tracking fingerprinted a separate issue per channel name (the signal only looked new because a fresh name minted a fresh fingerprint). The same unfiltered path applied to the CLI's other expected errors (Missing API key, Missing appId, Insufficient permissions for channel …).

Changes

• Add a CliUserError marker class for expected, user-facing CLI failures (precedent: MacOSSigningError, BuildRecordReadError). shouldCapturePosthogException skips it, so these never open an error tracking issue — while trackCommandFailed / categorizeCliError still count the failure.
• Gate the non-Commander branch of the global catch on shouldCapturePosthogException — it previously captured unconditionally, which is why marking the error alone would not have been enough.
• Throw CliUserError from the expected-failure branches in cli/src/channel/currentBundle.ts, and move the channel name out of the thrown message into a context property so any residual fingerprints collapse into one issue instead of one per channel. The user-facing log.error lines (which still include the channel name) are unchanged.

Out of scope (noted in the report): the telemetry sanitizer's dotted-name regex that mangles some channel names into <app_id> — moot now that these are no longer captured, so left untouched.

Test plan

• bun run test:posthog-exception — extended to assert CliUserError is never captured (with and without channel context) and that two failures on different channels produce an identical message (one issue, not one per channel).
• bun run typecheck and bun run lint:ox pass.

Screenshots

N/A — telemetry-only change; no visible CLI output change (the user-facing error messages are unchanged).

Checklist

• My code follows the code style of this project and passes
  bun run lint:backend && bun run lint.
• My change requires a change to the documentation.
• I have updated the documentation
  accordingly.
• My change has adequate E2E test coverage.
• I have tested my code manually, and I have provided steps how to reproduce
  my tests

---

Created with PostHog Desktop from this inbox report.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[codspeed-hq]

Merging this PR will not alter performance

✅ 43 untouched benchmarks
⏩ 2 skipped benchmarks¹

---

_{Comparing posthog-self-driving/fixcli-stop-reporting-expected-cli-user-9d6e33 (5b0c05b) with main (60a641e)}

Footnotes

1. 2 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud