test(twohost): assert the durable state, not the reply discriminant

Golden #272 r2 attempt 4 red twohost-a at the A-3 setup suspend:
"A-3 setup suspend applied an edge at B: NoEdge". The rung asserted
`matches!(out, RestRequestOutcome::Edge(_))` — it treated the reply
discriminant as the witness that the state changed. The product declines
to promise that, in two places at this sha:

  resthost.rs module doc, "## Idempotence over the wire": "a redelivered
  rest op is naturally a `no_edge` reply — report, don't dedup. The
  request's `op_id` is correlation/tracing only."

  request_rest's doc: "`open_op` is the durable id for the exactly-once
  stream open (the attach discipline); the request line itself is
  unjournaled — a redelivered request is a natural `no_edge` at the
  target's pure table, reported not deduped."

Exactly-once covers the STREAM OPEN, explicitly NOT the request line. So
`no_edge` is a contract-conforming answer to a request whose edge an
earlier delivery already applied, and the assertion made the rung red on
behaviour the product documents as normal.

The evidence says that is exactly what happened. B applied a Suspend edge
to ID_B inside a 112 ms window bounded by rig_wait's 250 ms cadence, while
A's single request was answered `no_edge` at 02:44:22.4617Z; B's log shows
stream 85 attached twice, conn 120 at 22.4330Z and conn 122 at 22.4586Z,
the latter's close matching A's reply. Two independent lines — the flip
window and the double attach — agree on the instant.

All four wire-Edge assertions now go through one helper: Edge and NoEdge
are both accepted and PRINTED with a timestamp (which reply arrived is
real information about delivery, just not a verdict), and the rung fails
only on the outcomes that mean the op did not land.

NOTHING IS LOST. The witness is the durable observable each rung already
waits on immediately after the call — the registry row advertising
Suspended/Active at A, `read_rest` at B — and those are untouched. The
assert was the only part claiming something the contract does not promise.

Scope, deliberately narrow: the B side (the `read_rest` waits) is
untouched, and `wansend.rs` is product and untouched.

NOTE ON THE MECHANISM: why the request was delivered twice is still under
a separate read of the dispatcher's claim/retire path. This rider is
correct either way — if the double-serve is a product defect it remains
one, and a rig that over-asserts is a second, independent fault. Fixing
the rig does not close the product question and must not be read as
closing it.

Co-authored by: hertz
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WAw9XAcTR8oSwzYPsqZoY2