fix: Resolve docker-dev build failures for arm64 and macOS

[3Sangeetha3]

Fixes #640

This PR addresses multiple issues that were causing the make docker-dev command to fail for users on arm64 (Apple Silicon) machines.

1. Fixes Puppeteer/Chromium Build Failure

• Problem: The build failed during yarn install because puppeteer could not find a pre-built arm64 Linux binary for Chromium.
• Solution: This PR adds a RUN apt-get update && apt-get install -y chromium step to the Dockerfile-dev to install the required binary before yarn install is run.

2. Fixes Missing Python 'venv' Error

• Problem: The build failed a second time because the make install-deps-python command checks for a ./venv directory that hadn't been created.
• Solution: Added python3 -m venv venv to the Dockerfile to create the virtual environment before the make command is called.

3. Resolves macOS Port Conflict

• Problem: Running the container with make docker-dev-run failed with an "address already in use" error, as port 5000 is often used by the macOS AirPlay Receiver.
• Solution: Updated the docker-dev-run target in the Makefile to map to port 5001 on the host (-p 5001:5000) to avoid this common conflict.

With these changes, users on arm64/macOS can successfully build and run the development container.

[northdpole]

Thanks for the contribution! Just a couple comments and this is ready

[northdpole]

Host cannot be 0.0.0.0 this exposes your Dev server to the network. There's a reason it's localhost by default

[3Sangeetha3]

I added --host=0.0.0.0 because when Flask runs inside Docker, binding only to 127.0.0.1 makes the server reachable exclusively from inside the container. Even with -p 5001:5000, the host can’t access the app (resulting in ERR_CONNECTION_RESET), since Flask is not listening on the container’s external interface. Using 0.0.0.0 resolves that and makes the dev container usable on macOS and Linux.

Thanks for pointing this out — I’ll revisit this and look for an approach that keeps the default local behavior secure while still allowing the Docker-based setup to function correctly. I’ll update the PR with a cleaner solution.

[northdpole]

Why's this necessary?

[3Sangeetha3]

On macOS, port 5000 is often reserved by the system AirPlay Receiver service (ControlCe), so docker run -p 5000:5000 fails with: Error: address already in use

This prevents make docker-dev-run from working out-of-the-box for macOS contributors.

Mapping the container’s 5000 to a different host port (5001) avoids the OS-level port conflict while keeping the container port unchanged.

This change fixes the macOS dev experience without affecting Linux/WSL users.