feat: add game event buffering and persistence

Closes #14

See merge request !16

# Conflicts:
#   game/client/src/Game.tsx

Build react frontends, and only serve build artifacts.

Closes #15

See merge request !15

Introduces a new 'game_events' table and buffering system to track granular
game events (inputs, scores, system states) alongside the existing game runs.

Changes:
- db.js:
  - Create `game_events` table (sensor_id, event_data, timestamp).
  - Add `bufferGameEvents` function to handle JSON event serialization.
  - Update `flushBuffer` to perform a single transaction for both runs and events.
  - Wrap database initialization in a transaction for safety.

- server.js:
  - Integrate `bufferGameEvents` into `sendMonitorEvent` for automatic logging.
  - Add source tracking (arduino vs frontend) to input events.
  - Add system events for client/monitor connections and disconnections.
  - Capture 'speed' events from Arduino.

fix : docker container conection to arduino serial port, review of the error message on server js

See merge request !14

Fixed our envs setup in regards to the docker compose file.

Closes #13

See merge request !13

updated ./readme.md to reflect new changes of our project

Closes #10

See merge request !12

docker compose automation file (first approach)

Closes #12

See merge request !11

simple docker setup for the react clients (monitor/client & game/client)

Closes #7

See merge request !10

Dockerfiles for game/server and monitor/server

Closes #5

See merge request !9

Architecture reveiw

Closes #11

See merge request !8

Instead of using multiple socat commands for the data mirroring between the diffrent virtual serial bus links,
we will rather use only the arduino serial bus and then expose another websocket server for the monitoring
servers.

This way it is much easier to scale and the code is still decoupled between the game server and the monitor server
logic.

We can rollback, change the game and the monitor server event formats independently. We can also remove the
monitor server entirely, but I've choosed to leave it there in case we want to enrich the data before sending
it to the monitor client, besides we can imaging a local caching mechanism for the monitor server or another
spin of our pgsql db for it as well, this is why having a server is still a good idea.

add an intermediate buffer between the game/server and the database.

Closes #8

See merge request !7

add arduino code for the 4 digit 7 segement

Closes #9

See merge request !5

Imported bufferGameRun to replace direct saving." -m

Implemented conditional logic to buffer game stats on restart.

Added sensor ID constant for data traceability.

Introduced in-memory write buffer to batch inserts.

Implemented flush mechanism every 10 seconds.
Decoupled game loop from database latency.

Added Docker Compose configuration.

Created direct save logic on game restart

Added .env in gitignore to secure secrets

Modified server.js to handle two serial ports: Real (I/O) and Bridge (Output Copy)

Forwarding game events to the Monitor via the virtual bridge.

- Added sendToServer call with score 0 in the restart function, ensures the hardware display resets to 0 when a new game starts.

- Utilized 4-digit 7-segment display hardware.

- Implemented split-screen logic to show Score and Deaths.

- Arduino: Added arduino directory and implemented button input logic with debounce on pin A0 (INPUT_PULLUP).

- Game Server: Switched serial path from simulator (/dev/pts/4) to real hardware port (/dev/ttyACM0).

- Note: These changes only affect the game architecture, monitor services remain unchanged.

docker integration for monitor/server

Closes #1

See merge request !2

Client migration to React.js

Closes #2

See merge request !3

Closes #2

Merge branch 'dev-massigy-react' of https://www-apps.univ-lehavre.fr/forge/gm213204/arduinogg into dev-massigy-react

first basic version of the project

See merge request !1