feat(docker): add containerized support for dev and deployment [signoff]

[Fmstrat]

As I'm getting set up to see how MyTerms would fit into TOS management for communities, containerized development was required. This PR introduces Docker-based build and deployment workflows for OpenVTC, enabling reproducible builds and simplified local development.

Changes:

• docker/Dockerfile - Multi-stage build: compiles OpenVTC from rust:1, then produces a slim debian:trixie-slim deployment image with only runtime dependencies (ca-certificates, libpcsclite1).
• docker/builder.Dockerfile - Standalone development container with Rust toolchain and build dependencies (libdbus-1-dev, pkg-config, libpcsclite-dev).
• .dockerignore - Excludes secrets, IDE artifacts, logs, and git metadata from Docker build context.
• docker/DOCKER.md - Documentation covering containerized deployment and development workflows, including a convenience cargo alias for running commands as the host user.
• README.md - Added reference to the Docker documentation.

In the future, this could be set up to auto-build a package image in the GitHub Container Registry, as well.

[stormer78]

Thanks for this — the deploy/dev image split is the right shape and the .dockerignore secret exclusions are a good catch. A few things worth addressing before merge, the first two being the important ones:

1. The runtime image is likely missing libdbus-1-3, so the container probably won't start (inline comment).
2. The deployment image ships a debug build (inline comment).
3. The persistent-data path under .vscode/data/ should move somewhere non-IDE-specific (inline comment).

Smaller notes inline as well. One non-inline thought: the PR body mentions reproducible builds, but rust:1 / debian:trixie-slim are floating tags — worth pinning (e.g. rust:1.88-trixie) if the GHCR auto-build happens later, and it would be good to have CI at least build docker/Dockerfile so the images don't rot silently.

[stormer78]

Suspected blocker: the runtime image is likely missing libdbus-1-3. The workspace pulls in dbus-secret-service → libdbus-sys for the Linux keyring, and the lockfile has libdbus-sys 0.2.7 with only a pkg-config dependency (i.e. dynamic linking, not the vendored build) — that's why the builder stage needs libdbus-1-dev. A dynamically linked binary will fail at load time in debian:trixie-slim with error while loading shared libraries: libdbus-1.so.3.

Suggested fix: add libdbus-1-3 next to libpcsclite1, and verify with:

docker run --rm --entrypoint ldd openvtc /openvtc

(no not found lines should appear).

[stormer78]

This builds a debug binary, so the "slim deployment image" ships an unoptimized, symbol-heavy build. Suggest:

RUN cargo build --release -p openvtc

and copying from /build/target/release/openvtc below. -p openvtc also skips building did-git-sign, which isn't shipped in this image.

[stormer78]

Two notes here:

1. Because ADD . /build runs before cargo fetch, any source edit invalidates the fetch layer and re-downloads all dependencies — the "Cache a build layer for downloads" comment below doesn't actually hold. Either copy Cargo.toml/Cargo.lock (+ member manifests) first and cargo fetch before copying the rest, or use RUN --mount=type=cache,target=/usr/local/cargo/registry, which is simpler for a workspace.
2. Prefer COPY over ADD for plain directory copies (Docker's own lint flags this; ADD has extra URL/tar-extraction behaviors you don't want here).

[stormer78]

Minor: prefer apt-get over apt in scripts (apt warns it has an unstable CLI interface — the runtime stage below already uses apt-get). Also, a one-line comment explaining the addgroup --system messagebus workaround (dbus package postinst in containers?) would save the next reader a puzzle — it appears in both Dockerfiles.

[stormer78]

WORKDIR /data is set but nothing mounts or writes /data — the docs persist /root instead (config lives under $HOME). Either document mounting /data for something or drop this line so it doesn't imply it matters.

[stormer78]

Please move the persistent-data path out of .vscode/ — that's a VS Code settings directory, and users without VS Code (or with it, syncing settings) will find app data hidden there surprising. Something like .docker-data/ in the repo (gitignored) or ~/.openvtc-docker/ would be cleaner. Same applies to the .vscode/data/home path in the cargo alias below. Whatever directory is chosen should be added to .gitignore, since running the deploy image as root leaves root-owned files that pollute git status.

Also worth a note that --network host behaves differently on Docker Desktop (macOS/Windows), which matters since this tool talks to live VTA/VTC services.