reqtrail v0.4.0 — the verified send

reqtrail 0.4.0 — run sends https

run refused every https:// URL with transport.unsupported, exit 1, while
every example in the README is HTTPS. It sends them now.

Sending

$ API_TOKEN=... reqtrail resolve example.reqtrail.json
GET https://api.example.com/users?q=a%20b
Host: api.example.com  (derived)
Authorization: Bearer ••••

Substitutions
  url         {{baseUrl}}         variables.baseUrl  https://api.example.com
  headers[0]  {{$env.API_TOKEN}}  environment        •••• (masked)

resolve still sends nothing, ever. run prints the same request and then
sends it.

Certificate verification cannot be turned off

A certificate reqtrail cannot verify is exit 3 — bytes were attempted — and the
request is still printed, because the diagnosis is the product:

$ API_TOKEN=... reqtrail run workspace.json
GET https://localhost:42607/users
Host: localhost:42607  (derived)
Authorization: Bearer ••••

Substitutions
  headers[0]  {{$env.API_TOKEN}}  environment  •••• (masked)

not sent: DEPTH_ZERO_SELF_SIGNED_CERT

$ echo $?
3

There is no flag to skip verification, and the environment cannot skip it
either. Node reads NODE_TLS_REJECT_UNAUTHORIZED process-wide, so =0
disables certificate checking for everything else that process sends. reqtrail
passes rejectUnauthorized: true explicitly, which wins over it. With that
variable set, Node prints its own stderr warning saying validation is disabled;
under reqtrail that warning is false, and test/run-tls.mjs proves the send
still fails.

When verification fails, no request bytes reach the server. The test
receiver captures zero bytes on every refused certificate, so a secret in a
header never leaves the machine.

Exit codes, unchanged in meaning

0  resolved, or sent and answered
1  refused or unresolved — the fix is in your file
2  usage
3  send attempted and failed

An untrusted certificate, a certificate issued for a different host, and a DNS
failure are all 3.

What this release does NOT do

• send has no timeout. TLS adds a way to hang: a handshake against a
  silent host waits indefinitely. Known, and not fixed here.
• No proxy support, no HTTP/2, no client certificates. None of these worked
  over plain HTTP either.
• No test sends to port 443. The default-port Host derivation is confirmed
  by the captured resolve output above and by reading src/core/url.js, not
  by an automated test.
• The --json document still carries no version of its own.

Verification

npm test on a clean checkout of the tagged commit:

refusals    40/40        leak-audit  0 of 31 fixtures leak
selftest    201/201      ui          27/27
parity      7/7          server      51/51
server-slow 2/2          wire        22/22
wire-tls    16/16        run-tls     12/12

Sitting A, real Chrome: 14 of 16 predictions held, unchanged from 0.3.0.

HTTPS-EVIDENCE.md records all ten predictions, three of them falsified: the
line-count ceiling, the expectation that GitHub would flag the committed
test-only private key, and the estimate of how much the suite would grow. It
also records that main was broken for nine days before this work started, and
that --help claimed run refused HTTPS for one commit after it stopped
doing so.