Seal and open payloads on workflow and operator traffic

[pseudomuto]

The encryptor existed, but nothing installed it, so payloads still crossed the connection in the clear. This puts it on the workflow and operator clients of both servers. Admin traffic (including replication streams), goes out on the bare client still. The payload visitor cannot see inside it yet, but I will follow up with another PR for that.

The two sides are mirror images, so the peer only ever holds sealed data and the local cluster only ever sees it opened. Outbound seals requests and opens responses, as before. Inbound needs the reverse, opening what the peer sends and sealing what the local cluster returns, which is what the new Reverse option does. Both share one vault per connection.

Enabled now only decides whether to seal anything. As long as a default key policy is configured, both sides keep opening, so turning encryption off does not strand payloads sealed while it was on. A disabled config that still names keys opens payloads, and so contacts the KMS at startup (see note at the end).

Payloads that are already encrypted are not sealed again. A second layer round-trips through the proxy, but anything opening the data outside it, such as a codec in front of workers after handoff, would peel one layer and find another. Our own payloads are recognized by the full key-material contract rather than the encoding name, since other codecs use the same name. Encodings the customer's codec produces can be listed in alreadySealedEncodings. Anything unrecognized is still sealed, so a gap in that list costs an extra layer rather than putting plaintext on the wire (fail closed and all).

Note

A proxy with keys tries to open every payload carrying our sealed contract and fails the call if it cannot. A Cloud-side proxy must therefore have no encryption block (couldn't access the customer KMS anyway), and a customer proxy must list every key URI its data was sealed under.