fix: switch from vmThreads to threads pool to resolve CI "module is already linked" errors

## Root Cause Analysis
CI was failing with 78 "module is already linked" errors due to:
- Node.js 24.x + Vitest vmThreads pool triggering ESM linker bug
- Tests still import Sentry via production dependency chain:
  test → tool → utils/build → utils/command → utils/logger → @sentry/node
- vmThreads pool has known issues with native modules like Sentry

## Solution: Switch to threads pool
- Changed pool from 'vmThreads' to 'threads'
- Increased maxThreads from 1 to 4 for better performance
- threads pool handles native modules better than vmThreads
- Fixes the Node.js ESM linker issue while improving performance

## Evidence from dependency graph analysis
Using madge revealed the exact import chain still bringing Sentry into tests:
build_device.test.ts → build_device.ts → utils/build/index.ts →
utils/build-utils.ts → utils/command.ts → utils/logger.ts → @sentry/node

## Benefits
- Resolves CI "module is already linked" errors
- Better performance (threads faster than vmThreads)
- More robust handling of native modules
- Maintains all existing test functionality (1046 tests pass)

## Testing
- All tests pass locally with threads pool
- TypeScript compilation and linting clean
- No behavioral changes to test execution

Author: cameroncooke

vitest.config.ts

@@ -21,10 +21,10 @@ export default defineConfig({
       '**/__pycache__/**',
       '**/dist/**'
     ],
-    pool: 'vmThreads',
+    pool: 'threads',
     poolOptions: {
-      vmThreads: {
-        maxThreads: 1
+      threads: {
+        maxThreads: 4
       }
     },
     env: {