zmq: fail startup when address is in use #35613

Fixes #33715.

When a second node is configured to publish ZMQ notifications on an address that is already bound by another process, the notifier currently fails to initialize but the node continues starting up. This leaves getzmqnotifications empty and only reports the bind failure in debug logs.

This changes ZMQ initialization so that an EADDRINUSE failure from zmq_bind is propagated as an init error. The behavior remains scoped to an address-in-use bind failure, preserving the existing behavior that invalid ZMQ arguments do not take down the node.

A functional test was added to interface_zmq.py that starts one node with -zmqpubrawblock=<address> and verifies that a second node configured with the same address fails during startup.

Tested with:

• python3 -m py_compile test/functional/interface_zmq.py
• git diff --check
• cmake --build build-clang --target bitcoind -j 8
• python3 build-clang/test/functional/interface_zmq.py --configfile=build-clang/test/config.ini --cachedir=/private/tmp/bitcoin_zmq_cache_33715_a --tmpdir=/private/tmp/bitcoin_zmq_tmp_33715_b

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35613.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Thanks for your submission! The description and code changes match a pattern we sometimes see with PRs that lean heavily on LLM coding assistants. Because the project has such limited human resources for code review, we require code generated by LLMs to be reviewed by the author who submits them first.

It would help to know why you decided to open this PR (did you encounter a bug? find an open issue in repo?), how you reviewed the generated code, what you personally understand about it, how you tested the code before and after the change, etc.

If you don't understand the changes you submitted, we should close this PR. There are many other more helpful ways to contribute to the project, and we look forward to working with you there!

Please also reconsider the value of the PR given how limited our resources are for code review.

<!--85328a0da195eb286784d51f73fa0af9-->

🚧 At least one of the CI tasks failed. _{Task Alpine (musl): https://github.com/bitcoin/bitcoin/actions/runs/28279403101/job/84071114054} _{LLM reason (✨ experimental): CI failed because the build stopped on a -Werror=redundant-move compiler warning in src/zmq/zmqnotificationinterface.cpp (return std::move(notificationInterface);).}

<details><summary>Hints</summary>

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

• Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.

• A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.

• An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

</details>

I pushed d38c4f9 to address the CI warning from -Werror=redundant-move by returning the unique_ptr directly instead of std::moveing it.

I am keeping this PR as a draft. My local review focus for the current patch is the ZMQ notifier startup path: CZMQNotificationInterface::Create() now returns a util::Result so init can surface a fatal notifier bind error to AppInitInterfaces(), while non-configured ZMQ still returns an empty interface as before. The functional test exercises the duplicate ZMQ bind case with two nodes on the same endpoint.

I will not request review until I have re-run the relevant checks after CI comes back.