Restore a green build on master, and resolve vlib through a compiler wrapper

[metif12]

Restores a green build on master, and fixes a vlib resolution bug that this change
exposes.

On current master with V 0.5.2 the suite does not run at all:

handlers_test.v:3768:68: error: cannot use `u64` as `int` in argument 1 to `string.repeat`

handlers_test.v fails to compile, so its 454 cases never execute. Fixing that exposes a
second problem, described below.

What is in this branch

Consolidates four of my open PRs, plus one new fix, in the order they must land:

• v fmt compliance across 17 files (was chore: restore v fmt compliance on master #528)
• index_max_file_bytes + 1 is a u64 passed to string.repeat, which takes int
  (was fix: make index_max_file_bytes usable as a string repeat count #526)
• Windows paths interpolated into the Sublime Text handshake test are not JSON-escaped
  (was fix: escape interpolated paths in the Sublime Text handshake test #527)
• os.fd_dup2 sits inside an assert, and -prod removes assert statements along with
  their side effects (was fix: perform the stdin dup2 outside assert so it survives -prod #532)

The new fix: vlib resolution through a wrapper script

With the suite compiling, 7 of 454 cases failed. All seven were vlib lookups.

find_v_dir returned the resolved compiler executable's directory unconditionally:

fn find_v_dir() string {
	v_exe := resolve_v_compiler_exe()
	if v_exe == 'v' || !os.is_file(v_exe) {
		return ''
	}
	return os.dir(os.real_path(v_exe))
}

Every caller builds <find_v_dir()>/vlib, but the compiler on PATH is not always v.exe
sitting beside vlib. V's own Windows launcher is a wrapper script:

C:\Users\xman\v\.bin\v.bat   ->   @echo off  +  "C:\Users\xman\v\v.exe" %*

.bin contains only v.bat; the real vlib is one level up. So find_v_dir pointed at a
directory whose vlib does not exist, and every vlib lookup silently resolved to nothing.
Seven call sites are affected, spanning import completions, builtin type resolution, and
hover and go-to-definition for vlib symbols.

find_v_dir_from_exe now walks up from the executable until it finds a directory that
actually contains vlib, bounded to eight levels. A tree with no vlib anywhere on the way
up returns an empty string instead of a path whose vlib is missing.

This matters beyond the tests: any Windows user whose v is a launcher script gets empty
import completions and no vlib hover, with nothing logged.

Verification

All on Windows, V 0.5.2 (bb0d229), VLS_VLANG_V_REPO pointed at a checkout of vlang/v.

State	Result
master	handlers_test.v does not compile
this branch	7 passed, 7 total, v fmt -verify . clean

Measured directly for the vlib fix, with v resolved to the .bat wrapper and
C:\Users\xman\v deliberately absent from PATH:

	handlers_test.v
before the fix	7 failed, 447 passed
after the fix	454 passed, 454 total

New main_test.v covers the wrapper layout, the plain layout, a deeper nesting, a tree with
no vlib, an unresolved name, and a missing file.

Not verified: Linux and macOS, and nothing has run in CI yet. Everything above is local
Windows output.

[medvednikov]

Independent review completed by an agent separate from the fix agent.
Reviewed commit 6596485; no remaining blockers.

The wrapper lookup verifies the canonical compiler path and finds an existing vlib.
The macOS test helper now compares canonical temporary paths consistently.

Validation: v fmt -verify . and v . passed. All six existing test files passed;
all six new vlib-discovery tests passed after the test-helper correction.
Hosted CI is still pending and is not being represented as passed.