fix(cli): declare release and DOM test dependencies

[c8dhjp4tyv-bit]

Recreated on the rewritten main after #1109 was auto-closed during repository maintenance. The dependency declarations were ported onto the rewritten snapshot and bun.lock was regenerated with the current repository Bun version instead of copying the pre-rewrite lockfile.

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 while preserving the rewritten upstream lockfile

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

Prior validation before the history rewrite:

• 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

For this recreated branch, Bun 1.3.14 regenerated the lockfile from the current rewritten main. The resulting diff remains exactly 2 files with the same 18+/2- lockfile and 3+/1- package-manifest scope as the final old branch.

[codebuff-team]

Thanks for tracking this back through the repo rewrite — that's a good-faith effort.

The substance is simple and plausible: cli/package.json was missing tar and @types/react-dom as declared devDependencies despite the CLI workspace tests apparently importing them, so bun install on a clean tree would have failed typecheck/test resolution. Declaring transitively-used packages explicitly is a reasonable and low-risk fix, and the lockfile diff looks minimal and mechanical (bumping tar to 7.x pulls chownr@3, minizlib, @isaacs/fs-minipass, yallist@5, while correctly leaving the older nested tar-fs/lru-cache deps pinned at their old versions rather than upgrading them transitively - that's the right call).

A few things a maintainer will want to verify before porting, since this can't be validated from the diff alone:

1. Confirm tar is actually used directly by CLI workspace code/tests (not just transitively available before). If it's only used by the release wrapper scripts described in the body, double check whether those wrappers already vendor their own tar dependency, as your PR body claims - if so, this devDependency may be redundant rather than a fix for a real breakage.
2. Verify the @types/react-dom addition doesn't mask an existing type error elsewhere (i.e., that it was truly missing, not silently resolved via hoisting before).
3. Since bun.lock is machine generated, worth double-checking no other incidental version drift crept in beyond the described tar graph change.

Given the scope is tiny and mechanical, this is portable if the above holds up under a quick sanity check.

[c8dhjp4tyv-bit]

Verified all three dependency concerns on the recreated branch with Bun 1.3.14. tar is directly required by cli/release-core/launcher.js and the CLI release wrapper safety test; each published wrapper package also declares its own runtime tar dependency. react-dom/server is directly imported by nine CLI component/test files. bun run --cwd cli typecheck completes successfully. The PR diff remains exactly two files (cli/package.json and bun.lock), 21 insertions / 3 deletions; the lockfile changes are the expected tar@7 graph plus @types/react-dom, including nested old chownr@1.1.4 and yallist@4.0.0 for incompatible existing consumers. git diff --check passes.