Fix SURB: only hand out the innermost payload key, not every hop's

[aniampio]

Summary

• SURBs (Single Use Reply Blocks) used to carry a derived key/seed for every hop in
  the route (up to 5). Whoever used the SURB to send a reply (SURB::use_surb) would
  layer-encrypt the payload with all of them - i.e. they computed every layer of
  encryption themselves, exactly like a normal forward packet's original sender.
• That's a privacy bug: it lets the SURB user precompute the payload ciphertext that will
  exist at every point along the reply route. If they collude with the last mix node,
  that node can match the ciphertext it sees against what it was told to expect,
  confirming this packet belongs to this specific reply route - deanonymizing which
  original (anonymous) sender the reply is going back to.
• Fix: a SURB now carries only a single key/seed - the one for the last hop in the
  route (the innermost encryption layer). use_surb adds exactly one layer instead of
  looping over all of them.
• No change needed to per-hop packet processing: mix nodes already unconditionally
  unwrap() one layer with their own key regardless of packet type, and
  encrypt/decrypt with a given key are true inverses of each other regardless of what
  other layers are nested around them. So the transit-added layers can be undone later by
  whoever holds every hop's key (the SURB's original creator) - that "designated
  receiver" logic is tracked as separate follow-up work, not part of this PR.

Note:

• this is a breaking change
• The "designated receiver" logic (the real-world equivalent of what the integration test simulates) needs to be implemented wherever the actual SURB-reply recipient runs.

[aniampio]

As discussed with @jstuczyn this cannot currently be integrated into nym-client or deployed because we first need to move the removal of the final Sphinx layer from the last gateway to the client. Otherwise, the gateway does not hold the necessary cryptographic information to derive the plaintext (as it does for all forward packets).