fix: measure GBFS response cap in bytes, not string length (#45)

* fix: measure GBFS response cap in bytes, not string length

The 5 MB cap compared GBFS_MAX_BODY_BYTES against body.length, which is the
string's UTF-16 code-unit count rather than its byte size. Those match for
ASCII but diverge for multi-byte payloads, so a large non-ASCII response
could slip past the cap. Switched to Buffer.byteLength.

Closes #32

* docs(changelog): move the GBFS byte-cap entry into the current Unreleased section

---------

Co-authored-by: Bilawal Sidhu <106619546+bilawalsidhu@users.noreply.github.com>
Co-authored-by: Bilawal Sidhu <bilawal@metaversity.us>

CHANGELOG.md

@@ -13,6 +13,13 @@ of current runtime behavior, see [`docs/CURRENT-STATE.md`](docs/CURRENT-STATE.md
   global detections while reporting each dropped source twice, once as
   successful with its real count and once as failed.
 
+### Security
+
+- GBFS proxy body-size cap now measures the response in bytes
+  (`Buffer.byteLength`) instead of JavaScript string length, so the
+  `GBFS_MAX_BODY_BYTES` limit holds for multi-byte payloads and cannot be
+  overrun by non-ASCII upstream responses.
+
 ## [0.1.0] — 2026-08-31 — One-click install, keyless boot, Provider Settings
 
 ### Added

vite.config.js

@@ -3373,7 +3373,7 @@ function gbfsProxy() {
             return;
           }
           const body = await upstream.text();
-          if (body.length > GBFS_MAX_BODY_BYTES) {
+          if (Buffer.byteLength(body, 'utf8') > GBFS_MAX_BODY_BYTES) {
             res.writeHead(502, { 'Content-Type': 'application/json', 'Cache-Control': 'no-store' });
             res.end(JSON.stringify({ error: 'GBFS upstream response too large' }));
             return;