Unify `tracePropagation` vs `propagateTrace` option names

[RulaKhaled]

Follow-up from #23443 (Isaac's review).

httpIntegration now exposes tracePropagation, matching Deno and nativeNodeFetchIntegration. Core's HttpInstrumentationOptions and Node's outgoing instrumentation still use propagateTrace. The Node integration maps between them:

propagateTrace: options.tracePropagation ?? true,

Goal

Pick one name and use it end-to-end (public integration options + core HttpInstrumentationOptions + Node outgoing instrumentation).

Recommendation

Keep tracePropagation as the public name — Deno and node-fetch already use it, and it sits next to tracePropagationTargets. Rename core/internal propagateTrace to match, rather than renaming the public option back to propagateTrace.

Do not conflate this with propagateTraceparent (W3C traceparent header) or tracePropagationTargets (which URLs get headers).

Scope

• packages/core/src/integrations/http/types.ts (propagateTrace)
• Node httpIntegration / OutgoingHttpRequestInstrumentationOptions
• Deno httpIntegration (already tracePropagation publicly; still maps to propagateTrace)
• Call sites in client-subscriptions, client-patch, tests, docs

This is a breaking change if we rename either exported option, so it belongs in 11.0 rather than a later minor.

Out of scope

propagateTraceparent and tracePropagationTargets stay as they are.

[linear-code]

JS-3427