Log broadcast listener failures

[JjCyberz]

Fixes #716.

When the server statistics broadcast listener task exits, OPAL currently only triggers a worker shutdown. If the task failed because the broadcast URI host cannot be resolved, the useful exception stays buried in dependency DEBUG output and no OPAL server ERROR log points at the broadcast URI.

This PR replaces the anonymous done callback with a named handler that:

• reads the completed broadcast listener task result,
• logs an ERROR when the task has an exception,
• includes the configured broadcast URI and exception repr in the log message,
• still triggers the same graceful worker shutdown behavior afterward.

Validation:

• git diff --check
• python -m py_compile packages/opal-server/opal_server/server.py

Bounty note:

/claim #716

[netlify]

✅ Deploy Preview for opal-docs canceled.

Name	Link
🔨 Latest commit	0b49e3b
🔍 Latest deploy log	https://app.netlify.com/projects/opal-docs/deploys/6a01cd89f9f6410008516c6d

[JjCyberz]

Added a small unit test file covering the broadcast listener done-callback behavior:

• logs the broadcast URI and exception when the listener task failed
• logs cancellation separately
• still triggers the existing graceful shutdown path

Local verification run:

python -m py_compile packages/opal-server/opal_server/server.py packages/opal-server/opal_server/tests/test_server_broadcast_listener.py

I could not run the pytest target locally because this environment does not have pytest installed, but the test is isolated and uses monkeypatching only around the imported module logger and shutdown method.

[zeevmoney]

Thanks for this and for the clean, well-tested patch, @JjCyberz. Unfortunately the linked issue #716 was closed as stale by a maintainer ("This issue is stale and the bounty is more than a year old. Closing it."), so we won't be merging the competing bounty-claim PRs for it. There are also other open PRs targeting the same issue (#728, #874, #882, #884), and the broadcast reader-task health path is being reworked more broadly in the broadcaster reconnect/healthcheck effort (#915), which will cover this error surface. For those reasons we're going to close this PR. We appreciate the contribution and the careful handling of the CancelledError and result-read edge cases.