Restore root Bun/Turbo build contract and remove stale Ink peer mismatch

[seonghobae]

Current role

Concrete blocker issue for repository baseline reliability.

Current state

On current main:

• bun run build fails at the repo root because Turbo cannot resolve workspaces without a root packageManager field in package.json
• bun run test fails through the same missing-root-contract path
• bun run lint fails through the same missing-root-contract path, so current lint verification is not meaningful
• bun install emits warn: incorrect peer dependency "ink@7.0.1"
• .github/workflows/test.yml builds only packages/cli and installs bun-version: latest, which hides the root build contract failure instead of validating the repository baseline

Current code validity

This is current-code-valid and reproducible from main.

Current code evidence

Repro commands

bun install
bun run build
bun run test
bun run lint

Expected current evidence

• bun install warns about ink@7.0.1
• bun run build fails with Turbo workspace resolution error due to missing packageManager
• bun run test fails through the same root Turbo workspace resolution path
• bun run lint fails through the same root Turbo workspace resolution path

Files involved

• package.json
• packages/cli/package.json
• packages/cli/tsconfig.json
• .github/workflows/test.yml
• turbo.json

Root-cause diagnosis

1. The root package manifest defines Turbo workspace scripts but omits the root packageManager metadata required by current Turbo workspace resolution.
2. The CLI package still declares @json-render/core, @json-render/ink, ink, react, and @types/react, even though the current source tree has no active runtime imports for them.
3. @json-render/ink@0.16.0 is peer-incompatible with the resolved Ink 7 line, so the repository emits a warning on install even before feature work begins.
4. CI currently validates a package-local build path and unpinned Bun version instead of the repo-level build contract, which masks the baseline drift.
5. The current workspace lint script points to turbo lint, but no package-level lint task exists yet, so once the root contract is restored a package-level static check is still needed.

Proposed scope

• add the root packageManager field
• remove dead CLI dependencies and stale JSX config if they are unused
• add a package-level lint script for meaningful static verification
• refresh the lockfile
• update CI to validate the root build path with the Bun version derived from the root contract while keeping package smoke coverage

Relationships

• Parent/meta issue: Token interoperability roadmap #29
• Related issues: Feature: add CSS custom properties export (--format css-vars) for native CSS consumers #15, Support for Tailwindcss version 4.0 & above #19, Support creation of DESIGN.md from DTCG tokens.json #28
• Cross-cutting follow-up: Support OKLCH colors #27

External blocker evidence

Repository-level milestone wiring is not available from this account for this repository, so milestone intent is tracked in #29 instead of repository metadata.

Completion conditions

• bun install completes with no Ink peer warning
• bun run lint executes a real package-level static check and succeeds from the repo root
• bun run build succeeds from the repo root
• bun run test succeeds from the repo root through Turbo
• CI validates the root build contract directly
• no functionality regressions in package tests or smoke checks

[seonghobae]

Parent/meta issue: #29

This issue is the first execution slice because it fixes the repository baseline that currently blocks trustworthy root-level build/test automation.

Adjacent follow-up issues after this baseline cleanup:

• Feature: add CSS custom properties export (--format css-vars) for native CSS consumers #15 CSS custom properties export
• Support for Tailwindcss version 4.0 & above #19 Tailwind v4 export support
• Support creation of DESIGN.md from DTCG tokens.json #28 DTCG tokens.json -> DESIGN.md
• Support OKLCH colors #27 OKLCH colors (cross-cutting spec fidelity)

I attempted to wire this as a formal sub-issue under #29, but the current account does not have the required repository permissions for AddSubIssue, so the relationship is recorded here explicitly.