Time reply decoding and lane waits under NAPDOCK_TIMING

NAPDOCK_TIMING=1 prints two new lines: bridge_queued (how long a command waited for its lane) and bridge_decode (how long wire::read took, and on which thread).

Measured on a live session, neither planned change was worth making. The longest wait for the control lane was 6 ms, and every reply decode ran under 100 µs. Replies are bounded by the protocol, so decoding stays on the main thread. Part of #164.