pvtcoms Windows release — reproducible build provenance

The published binary is CONFIG-FREE and byte-for-byte DETERMINISTIC: nothing secret is baked in,
so the same source + toolchain always produce the same exe (timestamps stripped, paths remapped).
Trust comes from verifiability, not a CA signature.

toolchain identity (not wall-clock):
  rustc:  rustc 1.96.0 (ac68faa20 2026-05-25)
  cargo:  cargo 1.96.0 (30a34c682 2026-05-25)
  mingw:  x86_64-w64-mingw32-gcc (GCC) 13-win32
  target: x86_64-pc-windows-gnu
  SOURCE_DATE_EPOCH=1735689600
  config: config-free (relay config supplied at runtime via pvtcoms.conf / env)
  bundled obfs4 client (lyrebird.exe) sha256: 3edbec0b914668ff17e2ba08c93515e45c04f13e9966c0acdb387b4ce15f475c
    └ official Tor Project lyrebird (tor-expert-bundle, windows-x86_64) — shipped as a SEPARATE
      file next to pvtcoms.exe (NOT embedded, to avoid antivirus ML false positives). The exe
      launches it only when an obfs4 bridge is configured. It is the same binary inside Tor Browser.

VERIFY (anyone, no secrets needed): run scripts/build-windows-release.sh at the matching commit +
toolchain. The resulting pvtcoms.exe must match the SHA-256 below — there is ONE published hash and
everyone can reproduce it, because no per-deployment config is baked in. This proves the published
binary is exactly this source with no hidden backdoor.

CONNECT: the exe reads its relay config, in priority order, from (1) PVTCOMS_RELAY / PVTCOMS_RELAY_KEY
env vars, then (2) a 'pvtcoms.conf' file next to the exe (relay=<onion>, key=<hex>, optional pow=<n>).
Invited members receive a pvtcoms.conf alongside the exe; it is never part of the published binary.