fix(net): surface gvproxy bind errors through FFI

[G4614]

Surface gvproxy virtualnetwork.New bind failures (port-in-use, privileged-port, …) through the Go initErr channel → FFI errOut → BoxliteError::Network instead of swallowing them into an opaque box failure

Test plan

Two regression tests, each verified two-sided (fix reverted vs applied):

• gvproxy_port_conflict_fails_fast_with_named_error — host pre-binds the port, then boxlite run -p collides (EADDRINUSE).
• gvproxy_privileged_port_fails_fast_with_named_error — non-root boxlite run -p 80:80 (EACCES).

observed	pre-fix (main.go/ffi.rs reverted)	post-fix
box exit code	rc=0 — boots despite the bind failure	rc≠0 — fails fast
stderr	no gvproxy_create failed, no OS reason	gvproxy_create failed: … address already in use / … permission denied
test result	both FAIL (all 3 checks)	both PASS

Pre-fix the bind error was swallowed in a goroutine logrus line and the box booted with broken networking; post-fix it interrupts startup with the named OS reason.

[G4614]

Where the error is produced — gvproxy-bridge/main.go:440, inside the network goroutine:

go func() {
    vn, err := virtualnetwork.New(tapConfig)   // :440  the bind happens here (EADDRINUSE, EACCES, …)
    if err != nil {
        initErr <- err                          // :443  hand the error out of the goroutine
        return
    }
    initErr <- nil                              // :446  success
    // ...
}()

Where it's captured — main.go:534, gvproxy_create blocks until that goroutine reports back, and a non-nil result becomes a hard stop:

if err := <-initErr; err != nil {   // :534  wait for the bind result
    setErr(err)                     //        copy the reason into *errOut
    cancel(); delete(instances, id); listener.Close(); os.Remove(socketPath)
    return -1                       // :547  ← turn the failure into -1
}

Pre-fix there was no initErr: the goroutine only logrus.Error'd the bind failure and returned, and gvproxy_create fell straight through to return C.longlong(id) without waiting — so the error never reached the return value and the box booted with broken networking (the test's rc=0).

The Rust side (net/gvproxy/ffi.rs, if id < 0 => return Err(...)) already aborted box startup on -1; it simply never received one until this fix produced it.

[DorianZheng]

will this hurt performances in normal cases?

[G4614]

gvproxy_create_latency_test integrated for normal case (virtual network.New wait < 0.5ms threshold), usually 0.1~0.3ms on Amazon c8i.xlarge ubuntu 22.04

A/B test (latency increase because of this waiting) also in this range

thx for the instruction