fix(code): unblock main thread by decompressing skills zips off-thread

[k11kirky]

Summary

• PosthogPluginService.updateSkills() runs during startup and calls fflate.unzipSync on the downloaded skills + context-mill archives. Pure-JS sync decompression on the Electron main thread pegged CrBrowserMain for tens of seconds on launch, surfacing as an app-hang for users on v0.52.0 (Unresponsive for 81 seconds before sampling in the crash log).
• Swap to fflate's async unzip via a small unzipAsync promisify helper in extract-zip.ts. Used by both extractZip and the inner omnibus-zip path in update-skills-saga.ts. Async unzip yields the event loop so the main thread stays responsive during extraction.
• Build-time scripts (vite.main.config.mts, scripts/pull-skills.mjs) keep unzipSync — they don't run in the Electron app.

Root cause (from the crash log)

Main thread stuck at node::fs::FileHandle::CloseReq::Resolve → V8 → JIT'd JS for all 41/41 samples — the promise continuation right after await readFile(zipPath) resolves, which is exactly where unzipSync ran. All 4 libuv-worker threads parked in uv_cond_wait, confirming the hang was pure CPU on the main thread, not I/O. 1.3 GB footprint matched the fully-materialized decompressed zip held in memory.

Test plan

• pnpm --filter code typecheck clean
• pnpm --filter code test — all 1348 tests pass (one mock updated from unzipSync to async unzip)
• Manual: launch packaged build on a clean profile and confirm the app reaches the renderer without hanging while skills download

Generated-By: PostHog Code
Task-Id: 0270afde-6140-4867-bd57-52ae8a767a4d

[greptile-apps]

_{Reviews (1): Last reviewed commit: "fix(code): unblock main thread by decomp..." | Re-trigger Greptile}

[andrewm4894]

was just looking into this too when doing local dev for some inbox stuff