fix(serve): honor build.outDir from vite.config.ts

[YevheniiKotyrlo]

Summary

Fixes #701. one serve now honors build.outDir from vite.config.ts, matching what one build already does at packages/one/src/cli/build.ts:370.

Problem

// vite.config.ts
export default defineConfig({
  build: { outDir: 'build-out' },
  plugins: [one()],
})

one build       # writes to ./build-out/ as expected
one serve       # ENOENT: open './dist/buildInfo.json'  ← bug

packages/one/src/serve.ts:194-195 resolved outDir from CLI args only:

const outDir = args?.outDir || (FSExtra.existsSync('buildInfo.json') ? '.' : null) || 'dist'

The vite config's build.outDir was never consulted, so projects with a non-default outDir had to pass --outDir <dir> explicitly to every one serve invocation.

Fix

Layer the resolution to match the build command:

1. --outDir CLI flag (highest precedence)
2. cwd contains buildInfo.json → '.' — preserves the "cd into output dir then run" UX even when vite.config sets a non-default outDir
3. vite.config's build.outDir, read via a new loadViteBuildOutDir() helper in packages/one/src/vite/loadConfig.ts
4. 'dist' fallback

Why a new helper instead of reusing loadUserOneOptions

The first cut of this PR called the existing loadUserOneOptions('serve', true) wrapper. That throws via getUserOneOptions when globalThis.__oneOptions is unset, and the One plugin only sets __oneOptions on the metro-CLI path (if (process.env.IS_VXRN_CLI)). On the vxrn-as-vite-plugin path (bundler: 'vite' in one() options) the throw fired every time, the catch swallowed it, and the resolution silently fell through to 'dist' — i.e., the first cut was a no-op for Vite-native projects.

The new loadViteBuildOutDir() calls Vite's own loadConfigFromFile directly, reads loaded.config.build.outDir, and never touches __oneOptions. Works for both bundler modes.

The vite.config load is wrapped in try/catch so deploy bundles that ship only dist/ (without vite.config.ts) keep working.

Test plan

Validated end-to-end on Windows MSVC + Bun 1.3.13 against the curex/one downstream consumer:

• bunx tsc --noEmit clean.
• Vitest unit test for loadViteBuildOutDir with two fixtures (with-outdir returning 'build-out'; without-outdir returning undefined). Passes 2/2 in 220ms.
• Positive — vite.config has build: { outDir: 'build-out' }, no dist/, no --outDir: patched serve.mjs started on port 3000, curl http://localhost:3000/ returned HTTP 200. Resolution went through the new vite-config path.
• Negative — same fixture, unpatched serve.mjs: failed with ENOENT: no such file or directory, open 'C:\…\dist\buildInfo.json' — the exact reported bug. Confirms the fix is load-bearing.
• --outDir build-out flag wins (highest precedence): server starts on resolved outDir; verified by curl returning 200.
• cd build-out && one serve UX preserved: server starts via the cwd-buildInfo.json branch.
• Default project with no custom outDir: falls through to 'dist' correctly (verified by ENOENT against ./dist/buildInfo.json when dist/ is empty — the resolution chain reached the default as designed).

Notes

• Mirrors cli/build.ts:370 (viteLoadedConfig?.config?.build?.outDir ?? 'dist') — same field path, but resolved without the loadUserOneOptions wrapper for the Vite-native compatibility reason above.
• Found while validating the Windows path-fix PR (fix(one,vxrn,compiler,vite-plugin-metro): Windows path bugs across build/server/dev/native paths #702). Not Windows-specific; pure CLI ergonomics across all platforms.