fix(cli): declare release and DOM test dependencies

[c8dhjp4tyv-bit]

Summary

• declare tar, which the release launcher and wrapper safety tests import in the private CLI workspace
• declare @types/react-dom, which the CLI's server-rendering tests require for typechecking
• update bun.lock with the minimal dependency graph changes

tar intentionally remains a CLI workspace devDependency: the actual published wrappers (cli/release, cli/release-staging, and freebuff/cli/release) each already declare tar in their own runtime dependencies.

Validation

• CLI typecheck passes with exit code 0
• release wrapper repair test passes
• DOM-rendering component tests pass
• runtime smoke import confirms tar.c and renderToStaticMarkup resolve
• verified the tar 7 lockfile graph keeps incompatible older consumers nested (tar-fs/chownr@1.1.4, lru-cache/yallist@4.0.0) rather than upgrading them transitively
• git diff --check passes
• the fork-triggered Public CI workflow is currently action_required, so there is no completed GitHub CI result to claim yet

[codebuff-team]

Good catch if tar and @types/react-dom are genuinely used but undeclared in cli/package.json — relying on hoisted/transitive deps is fragile and can break on a clean install or lockfile regeneration. Declaring them explicitly is the right fix.

A few things worth double-checking before this is ported:

• tar is listed as a regular dependency import (release launcher) but placed under devDependencies alongside the test-only @types/react-dom. If tar is actually needed at runtime by the release launcher (not just tests), it belongs in dependencies, not devDependencies, or bundling could omit it.
• The lockfile diff bumps chownr 1.1.4 → 3.0.0 and yallist 4.0.0 → 5.0.0 as top-level resolutions (while keeping pinned copies for tar-fs/lru-cache via nested entries) — this looks like an artifact of bun install on top of newer tar. Worth confirming no other package in the tree accidentally picks up the newer majors unintentionally.
• No test/CI evidence attached beyond the PR description's prose; given this repo's convention, it'd be good to show actual command output (or an actual CI run) rather than a claim list.

Overall this is a small, plausible dependency-hygiene fix and easy to verify by re-running bun install --frozen-lockfile before the change. Please confirm whether tar needs to be a runtime dependency rather than a dev dependency, since that changes correctness for anyone consuming the built CLI package.

[c8dhjp4tyv-bit]

Checked the two dependency concerns against the release layout.

tar should remain a devDependency of the private cli/ workspace. cli/release-core/launcher.js imports it in source/test/build contexts, but every published wrapper owns the runtime dependency in its own package manifest: cli/release/package.json, cli/release-staging/package.json, and freebuff/cli/release/package.json all declare tar under dependencies. Moving it to cli/package.json#dependencies would not be what makes the published wrappers correct; they are already self-contained.

The lockfile major changes are also scoped to the new tar 7 graph: tar gets chownr@3/yallist@5, while the existing consumers that require the old majors retain nested entries (tar-fs/chownr@1.1.4 and lru-cache/yallist@4.0.0). So the lockfile is preserving the incompatible consumers rather than accidentally upgrading them.

The PR head also has a Public CI workflow run, but GitHub currently reports it as action_required for the fork-triggered run rather than giving us a completed CI result to cite. I won't claim CI output that did not actually execute.