Honor single-trace WebSocket configuration for locally initiated spans

[lrwh]

What Does This Do

When DD_TRACE_WEBSOCKET_MESSAGES_SEPARATE_TRACES=false, start locally initiated websocket.send and websocket.close spans as children of the WebSocket handshake span.

The default separate.traces=true behavior remains unchanged: locally initiated spans follow the active context and link back to the handshake span.

The shared WebSocket assertions and both Javax/Jakarta regression suites now cover locally initiated send and close spans in single-trace mode.

Motivation

Solves #12390.

The single-trace configuration already places receive and peer-initiated close spans on the handshake trace, but locally initiated send and close spans ignored it. Without an active application span they became roots of unrelated traces; with an active span they joined that span's trace instead.

Additional Notes

Validation:

• ./gradlew :dd-java-agent:instrumentation:websocket:javax-websocket-1.0:test --tests '*WebsocketTest' :dd-java-agent:instrumentation:websocket:jakarta-websocket-2.0:test --tests '*WebsocketTest' --no-daemon
• git diff --check datadog/master...HEAD
• Tyrus 2.2.0/Grizzly runtime demo with traces sent successfully to a local DataKit endpoint on port 9529
• Verified that handshake, send, receive, and locally initiated close spans share the same trace ID and that send/close use the handshake span as their parent
• Verified that reconnecting creates a new trace ID for the new WebSocket session

The local root spotlessCheck task could not complete because spotlessInternalRegisterDependencies failed to provision external Eclipse P2 dependencies. No formatting changes were produced, and the targeted WebSocket tests compile and pass.

No new configuration or instrumentation module is introduced; this aligns the existing implementation with the documented configuration semantics.

Contributor Checklist

• Format the title according to the contribution guidelines
• Maintainer: add type: bug fix, inst: websocket, and tag: ai generated labels (external contributors cannot apply repository labels)
• Reference the issue using solves
• No source files were added, migrated, or deleted, so CODEOWNERS does not need an update
• No new configuration flag or public documentation change is required

Jira ticket: N/A (external contributor)