Windows: generated omo.cmd uses invalid quote comparison and exits 255

## Summary
On Windows, the generated `omo.cmd` launcher exits with code 255 before dispatching to Bun or Node. This breaks direct `omo` CLI usage, including `omo ulw-loop`, while the plugin hooks and MCP servers can still load normally.

## Environment
- LazyCodex version: 4.19.1
- Codex version: 0.144.5
- OS: Windows 10.0.26200 x64
- Install method: `npx lazycodex-ai install`
- Relevant config: `omo@sisyphuslabs` enabled; plugin hooks and Git Bash, CodeGraph, and Context7 MCP entries enabled

## Repository Decision
- Target repository: `code-yeongyu/lazycodex`
- Why this belongs there: the failure is emitted by LazyCodex's generated Windows command wrapper before Codex or the OMO Node runtime starts.
- LazyCodex evidence: the latest `v4.19.1` source at commit `3efc603ac474f5a4f77001641d0b2736dc121e85` generates the malformed conditions in `plugins/omo/dist/cli-node/index.js:74482-74483`.
- Upstream Codex source evidence: the failure reproduces in an isolated ASCII-only `.cmd` snippet without invoking Codex, so upstream Codex is not on the failing path.

## Reproduction
1. Install LazyCodex on Windows:

```powershell
npx lazycodex-ai install
```

2. Run the generated launcher from the installer bin directory, for example:

```powershell
& "$env:USERPROFILE\.local\bin\omo.cmd" --version
$LASTEXITCODE
```

3. Observe the command parser failure before either runtime is invoked.

Minimal isolated reproduction:

```bat
@echo off
setlocal EnableExtensions EnableDelayedExpansion
set "OMO_NODE_BINARY=node"
if "!OMO_NODE_BINARY:~0,1!"=="^"" set "OMO_NODE_BINARY=!OMO_NODE_BINARY:~1!"
echo SURVIVED
```

## Expected Behavior
`omo.cmd --version` should print the installed LazyCodex version and exit 0. `omo ulw-loop` should dispatch to its generated command wrapper.

## Actual Behavior

```text
The syntax of the command is incorrect.
exit code: 255
```

The isolated reproduction fails under both code page 65001 and 437. It also fails with ASCII-only paths, so the behavior is not caused by a non-ASCII Windows user profile.

## Evidence
- Installed wrapper contains:

```bat
if "!OMO_NODE_BINARY:~0,1!"=="^"" set "OMO_NODE_BINARY=!OMO_NODE_BINARY:~1!"
if "!OMO_NODE_BINARY:~-1!"=="^"" set "OMO_NODE_BINARY=!OMO_NODE_BINARY:~0,-1!"
```

- Latest source generates those lines in `windowsNodeDiscoveryLines()`:
- `plugins/omo/dist/cli-node/index.js:74482`
- `plugins/omo/dist/cli-node/index.js:74483`
- The malformed comparison was reproduced twice with exit 255.
- Replacing only `=="^""` with `==""""` made the isolated wrapper print `SURVIVED=node` and exit 0 twice.
- Running the bundled Node runtime directly still works:

```text
4.19.1
DIRECT_OMO_NODE_EXIT=0
```

## Root Cause
`windowsNodeDiscoveryLines()` emits `=="^""` when it tries to compare the first or last character of `OMO_NODE_BINARY` with a double quote. That sequence is not valid CMD comparison syntax, so `cmd.exe` aborts parsing before the wrapper reaches runtime discovery or dispatch. Both `windowsCommandShim()` and `windowsRuntimeWrapper()` consume the shared generated lines.

## Proposed Fix
Generate the valid CMD quote comparison:

```bat
if "!OMO_NODE_BINARY:~0,1!"=="""" set "OMO_NODE_BINARY=!OMO_NODE_BINARY:~1!"
if "!OMO_NODE_BINARY:~-1!"=="""" set "OMO_NODE_BINARY=!OMO_NODE_BINARY:~0,-1!"
```

Add a Windows regression test that writes the generated wrapper and executes it through `cmd.exe /d /c`, rather than only checking the generated text. Cover both quoted and unquoted `NODE_REPL_NODE_PATH` values because the shared helper is used by component command shims and the root `omo.cmd` runtime wrapper.

## Verification Plan
- [ ] `omo.cmd --version` prints `4.19.1` and exits 0 on Windows.
- [ ] `omo.cmd ulw-loop --help` reaches the ulw-loop wrapper.
- [ ] Generated wrappers accept quoted and unquoted `NODE_REPL_NODE_PATH`.
- [ ] The wrapper succeeds under Windows code pages 65001 and 437.
- [ ] Existing Codex plugin installer and bootstrap tests remain green.

---
This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated