Drop ZMQ sends after stop, so a late announce cannot leak a socket

[mikelangmayr]

Surfaced by the keygrabber's tests, which create and close a ZMQ Client per case and produced a ResourceWarning for an unclosed DEALER.

• ZmqTransport.send returns early once _stop is set. Sending creates a DEALER per peer on demand and stop() closes the ones that exist, so a later send opened one that nothing would ever close
• It is reachable in normal use, not just in tests: bamboo's Discovery.stop() only sets a flag and never joins its thread, and that thread sits in time.sleep(every_seconds). So up to one announce interval after Libby.stop() closed every socket, discovery can still broadcast. Client.zmq enables discovery by default with a 2s interval, so every stopped ZMQ client could leak one DEALER per address-book entry
• Add tests/test_zmq_transport.py. One case asserts a live broadcast does open a dealer, so the leak is demonstrably reachable rather than hypothetical, and the rest assert nothing is opened after stop. Confirmed they fail without the guard
• The whole suite now passes under -W error::ResourceWarning, which it did not before

Worth knowing separately: ZMQ's broadcast:* only iterates the sender's own address book, so discover=True over ZMQ announces this peer to peers it was already told about and never learns a new one. Over RabbitMQ the same call fans out through an exchange. The name suggests more symmetry than there is.

Also noticed while opening this: #35 widened pull_request to every base branch, but the paths lists still omit .github/workflows/**, so a workflow-only PR triggers no checks. That is why #35 itself reported none. Not fixed here.