Make Dockerfile.dev built containers a drop-in for production images.

Without this change, you can't easily swap a dev container for a production
(release) container because there are fundamental differences.  Allowing it
to be a drop-in replacement makes it easier to test on real fabrics.

- Use the same (environment variable) mechanism for configuring the default
  data path for consistent overrides.
- Use the same uid (1000) so permissions match.
- Add --ignore-scripts to npm ci to prevent build lifecycle scripts from
  running before source code is copied.

Author: rspier

docker/matterjs-server/Dockerfile.dev

@@ -31,14 +31,21 @@ COPY packages/dashboard/package*.json ./packages/dashboard/
 COPY packages/matter-server/package*.json ./packages/matter-server/
 
 # Install dependencies
-RUN npm ci
+RUN npm ci --ignore-scripts
 
 # Copy source code
 COPY . .
 
 # Build all packages
 RUN npm run build
 
+# Initialize data volume with user permissions
+RUN mkdir -p /data && chown -R 1000:1000 /data
+
+# Environment variables with defaults
+ENV LOG_LEVEL=info
+ENV STORAGE_PATH=/data
+
 # Data volume for persistent storage
 VOLUME ["/data"]
 
@@ -53,7 +60,10 @@ COPY --chmod=0755 docker/matterjs-server/healthcheck.sh /usr/local/bin/healthche
 HEALTHCHECK --interval=60s --timeout=10s --start-period=30s --start-interval=5s --retries=3 \
     CMD ["/usr/local/bin/healthcheck.sh"]
 
+# Run as non-root user
+USER 1000:1000
+
 # Run the matter server with data stored in /data
 # --enable-source-maps provides better stack traces in error logs
 ENTRYPOINT ["node", "--enable-source-maps", "packages/matter-server/dist/esm/MatterServer.js"]
-CMD ["--storage-path", "/data"]
+CMD []