fix: Surface meaningful error messages for connection failures

[MattDevy]

Summary

• ConnectionError now returns connection_error code with the target URL appended to the message (e.g., connection failed (http://localhost:19999/)) instead of an empty transport_error message
• TimeoutError now returns timeout_error code with the original timeout message preserved
• Generic transport errors remain as transport_error for any other error types

Test plan

• 6 new regression tests covering: non-empty message, empty message with URL from meta, both message and URL, empty fallback, timeout errors, generic transport errors
• Full test suite passes (513/513)
• Lint clean
• Build clean

Closes #99

[MattDevy]

This fix works around two upstream issues in @elastic/transport that I've reported:

• ElasticsearchClientError does not propagate Error.cause (ES2022 error chaining broken) elastic-transport-js#365 -- ElasticsearchClientError doesn't propagate Error.cause, so the original system error is lost when the transport layer rewraps connection errors
• ConnectionError surfaces with empty message when socket error lacks details elastic-transport-js#366 -- ConnectionError can surface with an empty message when the underlying socket error lacks details, despite the target URL being available in the DiagnosticResult metadata

If those are addressed upstream, the connectionMessage() helper here could be simplified (or removed) since the library would provide meaningful messages directly.

[MattDevy]

Hey @JoshMock, a small note on the ?? to || revert in the latest commit: the empty string case is the actual bug we're fixing here. The transport library surfaces ConnectionError with message: "" for socket failures, so we need || to catch that and fall back to 'connection failed'. With ??, the empty string passes through since it's not nullish, which re-introduces the original issue.

[JoshMock]

Thanks for catching that @MattDevy! ❤️