fix(ci): make unit (windows) green — core git-suite timeouts, step budget, skill-refresh rename hardening (LAC-2717)

[lacymorrow]

Paperclip issue

LAC-2717 — Fix unit (windows) CI failures: @opencode-ai/core ProjectCopy/RepositoryCache tests time out at 5s on GitHub-hosted runners.

Summary

Makes the unit (windows) job pass on GitHub-hosted runners. The scope grew as each fix exposed the next failure layer (the job had never run to completion on hosted Windows):

1. Per-suite 30s test timeout for git-heavy core suites (project-copy, repository-cache, and now snapshot) via a testEffect(layer, defaults) per-suite default instead of a package-wide --timeout — a blanket 30s would hide regressions in fast tests (per Gemini review). These suites chain git subprocess ops that cost 100ms–2.8s each under full-suite load on 4-core hosted Windows runners, blowing bun's 5s default.
2. CI step budget + observability: timeout-minutes on the unit step (the opencode suite alone takes ~18.5–20 min on hosted Windows; the old 20-min budget killed the step mid-run once earlier suites stopped failing fast) and --log-order=stream so a killed step keeps partial turbo output instead of losing 18 min of buffered logs.
3. turbo env passthrough for @opencode-ai/core#test: turbo 2.x strict env mode silently stripped the workflow's OPENCODE_EXPERIMENTAL_DISABLE_FILEWATCHER=true, so the file watcher booted in Windows core tests against the workflow's stated intent.
4. Windows rename hardening in Discovery.pull skill refresh: Defender/indexer briefly holds handles on freshly written directories, so the staging→root directory swap can fail with EPERM even though the swap is valid; retry like graceful-fs does. Seen as Discovery.pull > refreshes a remote skill when its version changes returning stale content on run 29073953968.

Rebased onto LAC-2385/blacksmith-to-github-runners after the LAC-2693 fixes and dev merge landed there; overlapping test fixes (cwd expectations, routing casing, path-variant tests, prompt loop timeouts) were dropped in favor of the versions already on the base branch.

Acceptance criteria

• unit (windows) reaches success on GitHub-hosted runners on the integration branch.

Testing

• Locally (macOS): snapshot, discovery, project-copy, repository-cache, and touched opencode suites pass; tsgo --noEmit clean in both packages.
• Windows verification is CI-only: run on this branch must show unit (windows) green. Prior run 29071790348 already showed core 1046 pass / 0 fail for the first time on hosted Windows.

[gemini-code-assist]

Code Review

This pull request adds a 30-second timeout to the test script in packages/core/package.json and documents the reasoning in bunfig.toml due to slow git-subprocess tests on Windows runners. The reviewer suggests isolating these slow tests into a separate test suite or script to prevent hiding performance regressions in tests that should run quickly.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

While this fixes the immediate issue on Windows runners, applying a 30s timeout to all tests in the package could hide future performance regressions in tests that are expected to be fast.

A more targeted approach would be to isolate the slow, git-heavy tests and apply the longer timeout only to them. You could achieve this by:

1. Grouping the slow tests into a specific directory or using a naming convention (e.g., *.slow.test.ts).
2. Creating a separate test:slow script in package.json that runs only these tests with --timeout 30000.
3. Adjusting the main test script to exclude these slow tests and run with the default timeout.
4. Ensuring your CI pipeline runs both test scripts.

This would maintain a stricter performance baseline for the majority of your tests.

[lacymorrow]

Addressed in d03e065. Agreed — the package-wide --timeout 30000 is gone. The testEffect helper now accepts a per-suite default (testEffect(layer, { timeout: 30_000 })), applied only in project-copy.test.ts and repository-cache.test.ts (the two git-subprocess-heavy suites). All other core tests keep bun's 5s default, so fast-test regressions stay visible. Per-test opts still override the suite default. One note on the exact suggestion: setDefaultTimeout() was avoided because bun runs all test files in one process, so it would leak to files loaded afterwards.