Direct launcher crash reports to product issues tracker

[nordicnode]

Direct launcher crash reports to product issues tracker

Summary

• In cli/release-core/launcher.js, parameterize the issue tracker URL in printCrashDiagnostics with packageName (https://github.com/CodebuffAI/${packageName}/issues).
• Previously, printCrashDiagnostics dynamically parameterized diagnostic outputs with ${packageName} and ${packageName.toUpperCase()}_BINARY_TARGET, but hardcoded https://github.com/CodebuffAI/codebuff/issues for the issue reporting URL.
• When Freebuff CLI users experience an immediate exit or native crash (e.g. on unsupported CPUs, missing GLIBC, or missing AVX2), they were instructed to report the issue at CodebuffAI/codebuff rather than CodebuffAI/freebuff.
• Adds a regression test in cli/src/__tests__/release/wrapper-safety.test.ts verifying that printCrashDiagnostics outputs the product-specific issue tracker URL for freebuff and codebuff.

Test plan

[✓] bun test --config=/dev/null src/__tests__/release/wrapper-safety.test.ts — 18 pass, 0 fail (including new issue URL regression test)
[✓] bun run --cwd cli typecheck — 0 errors
[✓] node --check cli/release-core/launcher.js — syntax valid
[✓] PR hygiene check passed

[codebuff-team]

Good catch and a clean, minimal fix. The other diagnostic strings in printCrashDiagnostics already interpolate packageName, so hardcoding the GitHub issues URL to CodebuffAI/codebuff was clearly an oversight — Freebuff users hitting a crash would have been sent to the wrong repo. The one-line fix in launcher.js is correct and consistent with the existing pattern.

The added test in wrapper-safety.test.ts is a reasonable regression check, though it does rely on createLauncher(...).__testing.printCrashDiagnostics being an intended test seam — worth confirming that's the sanctioned way to reach this internal function elsewhere in the test suite, but it looks consistent with prior tests.

One thing to double check before porting: does CodebuffAI/freebuff exist as an actual GitHub repo with an issues tracker enabled? If not, this fix is correct in intent but would send users to a 404 until that repo exists. Worth a maintainer note in the PR or an issue link showing it resolves correctly for both products.

Overall: small, focused, in-scope, with a test. Worth porting.