[Server] Gzip-compress /api/bootstrap and /api/resync responses

[LarsLaskowski]

📖 Description

/api/bootstrap and reset-mode /api/resync can return up to serverMaxSyncLines (≤ 500) full LogLine objects — roughly 150–250 KB of repetitive JSON (rawLine/message both carry the line text, plus timestamps and logger names duplicated across rows). This log-shaped text compresses very well, so responses are now gzip-compressed via the standard compression middleware.

The middleware is added as a new small module, createApiCompression() in src/server/apiCompression.ts, and mounted only under /api, ahead of the router. /api/stream is explicitly excluded, since compression's write-buffering would delay or batch SSE events and defeat live delivery.

One implementation detail worth calling out: compression's filter callback runs lazily on first write rather than at mount time, so by the time it runs, Express has already restored request.path to the full incoming path (/api/stream), not the router-relative path (/stream) a synchronously-invoked middleware would see at the same mount point. This was verified with a test (see below) rather than assumed, per the issue's own caution about this.

🎫 Issues

Closes #140

👩‍💻 Reviewer Notes

• New dependency: compression (+ @types/compression dev dependency) — this was option 2 in the issue, the recommended implementation if compression is wanted.
• /api/health stays uncompressed automatically (small responses fall under compression's default 1 KB threshold).
• dist/client static serving and /api/stream are both left untouched.
• Suggested smoke test: GET /api/bootstrap with Accept-Encoding: gzip and confirm a Content-Encoding: gzip response header; GET /api/stream and confirm no Content-Encoding header and immediate event delivery.

📑 Test Plan

• New src/server/apiCompression.test.ts:
  • gzip-compresses a large /api/bootstrap response and preserves the JSON body — asserts Content-Encoding: gzip and that the JSON body round-trips correctly.
  • never compresses /api/stream so SSE delivery is not buffered — asserts no Content-Encoding header is set for /api/stream.
• npm test (157/157 passing), npm run typecheck, and npm run build all pass locally.

✅ Checklist

General

• I have added unit tests for my changes, per UNIT_TESTS.md.
• I have run npm test and npm run typecheck locally and they pass.
• I have updated the project documentation (README, ARCHITECTURE, etc.) to reflect my changes, where applicable.
• I have read the CONTRIBUTING documentation and followed the project's code style and conventions.

Server-specific (src/server)

• I have added or updated a module in src/server (tailer, parser, buffer, routes, SSE hub, config, etc.).
• I have kept src/server/types.ts in sync with src/client/state.ts for any shared payload change (see ARCHITECTURE.md). — not applicable, no payload shape changed.
• I have preserved existing server-side bounds and defaults (buffer/SSE limits, poll interval clamps) unless the change explicitly targets them.

⏭ Next Steps

Create release - version 2.5.0

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud