fix(build): resolve repo root with fileURLToPath so builds work on Windows

[redliuziqi]

Fixes #240

Problem

scripts/build-bundles.mjs resolved the repo root with new URL("..", import.meta.url).pathname. That returns a URL path, not a filesystem path — on win32 it is /C:/Users/..., and path.resolve() treats the leading slash as relative, producing C:\C:\Users\....

Result on Windows: every build target dies immediately.

> bun run build:cli
  code: 'ENOENT',
  path: 'C:\\C:\\Users\\<user>\\agent-bridge\\package.json'

This blocks build:cli, build:plugin, prepublishOnly, verify:plugin-sync and the check gate — a Windows contributor cannot build or validate anything.

Fix

const repoRoot = resolve(fileURLToPath(new URL("..", import.meta.url)));

fileURLToPath performs the documented URL→path conversion (strips the leading slash, decodes percent-escapes) and is correct on all platforms. scripts/code-hash.cjs already resolves its root correctly via __dirname; this was the only URL-pathname occurrence in the repo, so the change is one line plus the import.

No behavior change on macOS/Linux — there pathname and the real path already coincide.

Validation

Windows 11, Bun 1.3.14, Node v22.14.0, base a3e927f (v0.1.30).

Three tests already in the suite fail on Windows purely because of this bug, so the fix is locked by existing coverage and no new test is needed:

	verify-plugin-sync.test.ts + build-info.test.ts + code-hash.test.ts
pristine master	20 pass / 3 fail
with this fix	23 pass / 0 fail

The 3 that flip green: build-bundles commit override (verify-plugin-sync mechanism) (2) and build-bundles codeHash stamping (1).

Also confirmed on this branch:

bun run typecheck      -> exit 0
bun run build:cli      -> exit 0   (was ENOENT)
bun run build:plugin   -> exit 0   (was ENOENT)

Notes for reviewers

• No bundle artifacts committed. bun run build:plugin on this branch does rewrite plugins/agentbridge/server/*.js, but the diff is unrelated rebuild noise: the embedded commit stamp, plus different minifier output because my local Bun is 1.3.14 while the repo pins 1.3.11. Per CONTRIBUTING that pairing belongs to a build on the pinned toolchain, so I reverted them and kept this PR to the script only. Someone on Bun 1.3.11 should do the bundle refresh separately.
• This does not make Windows green overall — with the fix I see 1485 pass / 33 fail (87 files). The rest are separate environment gaps tracked in Windows support: unblock the POSIX-only assumptions #231: symlink EPERM (needs Administrator/Developer Mode), Unix file-mode assertions (420/511), POSIX path joins in other scripts, and SIGKILL naming.
• src/unit-test/logs-cli.test.ts spawns tail, which does not exist on Windows. That aborts the whole bun test src/unit-test run rather than failing one test, so reproducing a full count requires excluding that file. Worth its own issue under Windows support: unblock the POSIX-only assumptions #231 — abg logs -f is presumably non-functional on Windows for the same reason.
• I have not signed the CLA; happy to do so if you want this merged.

---

中文说明：URL.pathname 在 win32 返回 /C:/...，resolve() 会拼成 C:\C:\...，导致所有构建目标读取 package.json 时 ENOENT 失败，Windows 上完全无法构建。改用 fileURLToPath 修复，POSIX 行为不变。仓库内仅此一处该写法。现有 3 个测试因此 bug 在 Windows 上失败，修复后转为全部通过（20 pass / 3 fail → 23 pass / 0 fail），无需新增测试。未提交 bundle 产物：本地 Bun 版本与仓库锁定版本不一致，重新构建的差异属于无关噪声。

[github-actions]

Thanks for the PR! Before we can merge it, please sign our lightweight Contributor License Agreement — it keeps the project able to offer a future commercial edition alongside the open-source one. Reply here with:

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}