fix(proxy): propagate origin status code and handle 304 correctly

[7ui77]

This PR fixes a critical issue in the web debugger's proxy server that was causing 'Unexpected end of JSON input' errors when debugging plugins.

Issue

The proxy was hardcoding the response status code to 200 and failing to propagate the actual status from the target server. When a server returned 304 Not Modified (with an empty body), the proxy would still send 200 but with the empty body. The plugin, expecting valid JSON for a 200 response, would then fail with a JSON parsing error.

Fix

• Removed hardcoded res.statusCode = 200.
• Implemented status code propagation in the proxyRes event handler.
• Added explicit handling for 304 responses to simply end the response without attempting to process a body.
• Improved decompression handling for various encodings (Brotli, Gzip, Zstd).

Verification

Verified using the Web Debugger with the NovelBuddy plugin. Subsequent "Fetch" requests that return 304 now correctly trigger the browser's cache usage instead of causing JSON parsing errors in the plugin.

[7ui77]

@K1ngfish3r mismatch between ArrayBufferLike (which includes SharedArrayBuffer). Try this:

const compressedBuffer = Buffer.concat(chunks);
if (compressedBuffer.length > 0) {
    let decompressedBuffer: Buffer;
    if (contentEncoding.includes('br')) {
        decompressedBuffer = brotliDecompressSync(compressedBuffer) as Buffer;
    } else if (contentEncoding.includes('gzip')) {
        decompressedBuffer = gunzipSync(compressedBuffer) as Buffer;
    } else if (contentEncoding.includes('zstd')) {
        decompressedBuffer = zstdDecompressSync(compressedBuffer) as Buffer;
    } else {
        decompressedBuffer = compressedBuffer;
    }
    res.write(decompressedBuffer);
}

[K1ngfish3r]

run prettier here too

[K1ngfish3r]

any reason why these two keys were specified here?

[7ui77]

client is now raw data. If you keep 'content-encoding: gzip', the browser will attempt to decompress it again, causing an error.
The data size after decompression will definitely change compared to the original. If you keep the old 'content-length', the browser will either freeze—waiting to receive the full original byte count—or throw an 'Unexpected end of data' error.

[K1ngfish3r]

this fixes covers on a few sources