fix(cli): resolve dynamic imports to file:// URLs so the DB fallback works on Windows

[pacocartones]

omniroute combo list, create, delete and switch all exit 1 on Windows whenever the server is offline and the CLI takes its direct-DB fallback path:

Error: Only URLs with a scheme in: file, data, and node are supported by the
default ESM loader. On Windows, absolute paths must be valid file:// URLs.
Received protocol 'e:'

Cause

import() resolves its specifier as a URL, not as a filesystem path.

A POSIX absolute path (/home/x/src/lib/db/combos.ts) also happens to be a valid relative URL, so interpolating it into import() works by accident on Linux and macOS. A Windows absolute path is E:\checkout\src\lib\db\combos.ts, and the loader parses the leading drive letter as the URL scheme e:, which it rejects.

Four call sites build a specifier this way:

File	Line
bin/cli/runtime.mjs	25, 26
bin/cli/commands/setup.mjs	19
bin/cli/commands/serve.mjs	384

runtime.mjs is the impactful one: importDbModules() is what every withRuntime/withDb caller depends on when isServerUp() returns false, so the entire offline fallback of the CLI is unreachable on Windows.

Fix

Route each specifier through pathToFileURL(...).href.

Verification

tests/unit/cli-combo-command.test.ts was already failing on Windows on a clean checkout of release/v3.8.50 (0b41259f3) — this is not a new test:

before: pass 1, fail 4
after:  pass 5, fail 0

The four failures were combo create, combo delete, combo list and combo switch, each asserting exit === 0 and getting 1.

That file also had a second, unrelated Windows problem: its withComboEnv teardown called fs.rmSync on the temp data dir while SQLite still held the file open, throwing EPERM and failing a test whose assertions had all passed. It now retries and degrades to best effort, since the OS reclaims its own temp dir anyway.

Regression guard

Adds tests/unit/cli/windows-esm-import-paths.test.ts, which does two things:

1. greps bin/cli for the import(`${SOME_ROOT}/...`) pattern, so a new call site cannot reintroduce this;
2. actually loads the DB fallback modules through withDb on the current platform.

Verified RED before the fix and GREEN after.

Scope

tests/unit/cli/** reports 182 tests, 170 pass, 9 fail both with and without this change — those 9 failures (aliasResolver, buildRunPlan, the outboundUrlGuard child-process specs) are pre-existing on 0b41259f3 and untouched here. I mention it so the number isn't attributed to this PR; happy to open a separate issue for them if useful.