feat(zk-prover): add standalone compose workflow

[mw2000]

Summary

• Add a standalone Docker Compose stack for running the ZK prover locally.
• Let local lifecycle commands infer the fixed prover stack and load network/cluster settings from local YAML.

Test plan

• just zk-prover
• docker compose -p zk-prover -f etc/docker/docker-compose.zk-prover.yml config --quiet
• git diff --check

Made with Cursor

[github-actions]

Review Summary

This PR adds a standalone Docker Compose stack (docker-compose.zk-prover.yml) and reworks the zk-prover.just recipes to support running the ZK prover independently from the full devnet stack. The compose file, env-file plumbing, and lifecycle recipes (up, down, logs) are well-structured and consistent with the existing devnet patterns in etc/docker/Justfile.

Findings

Minor: Fragile YAML generation via string concatenation (etc/just/zk-prover.just:192)

The inline Python one-liner generates a Docker Compose override file by concatenating a JSON-encoded path into a YAML template string. JSON and YAML double-quoted strings have subtly different escaping rules. While CA cert paths in practice are simple filesystem paths, consider using json.dumps to produce a JSON compose file (Docker Compose accepts JSON) to eliminate the escaping mismatch entirely.

Notes (no action required)

• The PR removes the target positional parameter from list, describe, prove, get, and list-proofs recipes. These now infer the endpoint from ZK_PROVER_ENDPOINT / ZK_PROVER_GRPC_PORT env vars. This is a breaking change for anyone calling these recipes with positional target args — intentional per the PR design, but worth noting in case other scripts depend on the old signatures.
• The compose file, healthcheck patterns, credential handling, and --deny guards for secrets in YAML configs all look correct and consistent with existing conventions.

[github-actions]

The zk-prover runtime image is based on debian:trixie-slim with only ca-certificates and curl installed (runtime-base stage in Dockerfile.rust-services). bash is not present in that image, so this healthcheck will always fail with exec: "bash": executable file not found.

Since curl is installed in the runtime base, you could use:

Suggested change

	test: ["CMD", "bash", "-c", "echo > /dev/tcp/localhost/9000"]
	test: ["CMD", "curl", "-sf", "http://localhost:9000/"]

Or if the gRPC endpoint doesn't respond to plain HTTP, a simple TCP check with the timeout utility (available in coreutils):

test: ["CMD-SHELL", "timeout 1 sh -c 'echo > /dev/tcp/localhost/9000' 2>/dev/null || curl -sf http://localhost:9000/ || exit 1"]

Note: /dev/tcp is a bash-only feature. For a POSIX shell alternative, consider using curl or installing netcat.