fix: await VirtualDisplay.get() — Xvfb DISPLAY becomes "[object Promise]", breaking all tab launches

[Francisgood]

Problem

On Linux/Docker builds with the Xvfb virtual display enabled (introduced in the Mesa GL + Xvfb WebGL change), every browser launch fails and POST /tabs returns 500:

[err] Error: cannot open display: [object Promise]
<process did exit: exitCode=1, signal=null>

The server log also records the display as an empty object — a serialized, unresolved Promise:

{"msg":"xvfb virtual display started","display":{},"attempt":1}

Root cause

VirtualDisplay.get() in camoufox-js is declared async and returns a Promise<string>:

// camoufox-js/src/virtdisplay.ts
public async get(): Promise<string> { ... }

In launchBrowserInstance() (server.js) it was called without await:

vdDisplay = localVirtualDisplay.get();   // vdDisplay is a Promise, not the display string

vdDisplay then flows into the launch options as virtual_display: vdDisplay. Camoufox stringifies it to the literal "[object Promise]" and hands it to Firefox as the X DISPLAY, so Firefox tries to open a display literally named [object Promise] and exits with code 1.

Fix

Add the missing await:

vdDisplay = await localVirtualDisplay.get();

launchBrowserInstance() is already async, so this is safe.

Verification

Built the image from the patched source and started a container. The crash loop is gone — the display now resolves to a real value and the browser pre-warms:

{"msg":"xvfb virtual display started","display":":0","attempt":1}
{"msg":"camoufox launched","attempt":1,"virtualDisplay":true}
{"msg":"browser pre-warmed","ms":3989}

A subsequent POST /tabs / page navigation succeeds. node --check server.js passes.

Impact

Without this, any fresh Docker build with the virtual display enabled cannot create a single tab. One-character change (await), no behavior change beyond correctly resolving the display string.

[grozmus]

I confirm the bug and that fix is working.