[ENHANCEMENT] Add packages/core integration-test Turbo lane for process-boundary suites #206

Problem (one or two sentences)

@roo-code/core:test:coverage currently mixes fast unit tests with slower subprocess-boundary tests, so Windows flake fixes and Turbo cache improvements are forced through one coarse package task.

Context (who is affected and when)

This came up while investigating the Windows CI failure after PR #81 merged. The failing tests in packages/core/src/worktree/__tests__/worktree-include.spec.ts exercise real git and platform copy commands, while custom-tools also includes real esbuild/dynamic-import pipeline tests. Keeping those behaviors in the same fast coverage lane makes the task harder to cache well and harder to stabilize without broad timeout changes.

This should be grouped under #47 so the packages/core task split follows the same Turbo/caching initiative rather than becoming a one-off workaround.

Desired behavior (conceptual, not technical)

packages/core should have a small reusable integration lane for process-boundary tests, separate from the ordinary fast unit lane. The first scope should cover:

• worktree / Git integration behavior
• custom-tools / esbuild pipeline integration behavior

Turbo should be able to schedule and cache that lane independently from the rest of @roo-code/core tests.

Constraints / preferences (optional)

• Keep this inside packages/core; do not create a new workspace package yet.
• Prefer package-local Turbo configuration and dedicated scripts/tasks over broad root-level changes.
• Do not sweep in all temp-dir or filesystem tests; only move suites that cross a real process / bundling boundary.
• Treat [ENHANCEMENT] Make roo-cline coverage tasks more cacheable in CI #47 as the parent initiative / umbrella.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Acceptance criteria (optional)

• packages/core has a dedicated integration test task (for example test:integration and/or test:coverage:integration) that Turbo can schedule independently.
• The worktree / Git integration coverage is separated from pure unit coverage.
• The custom-tools / esbuild pipeline coverage is separated from pure unit coverage.
• Fast unit coverage for unrelated @roo-code/core areas can hit Turbo cache without rerunning the process-boundary suites.
• CI can target the integration lane explicitly.

Proposed approach (optional)

1. Add package-local Turbo task definitions for packages/core.
2. Split Vitest coverage into unit vs integration configs/slices.
3. Move the real Git/worktree and real esbuild/custom-tools pipeline tests into the integration slice.
4. Keep pure parser / serializer / in-memory registry tests in the unit slice.

Trade-offs / risks (optional)

• This adds configuration and coverage-merge complexity.
• Poor boundaries could create confusing ownership or duplicate test setup.
• Moving too much into the integration lane would make it expensive and reduce cache wins.

Parent issue: #47
Related precedent: #43