feat(scope): remove Hub from Transaction

[Litarnus]

This PR removes the Hub from the transaction and instead replaces it with ClientInterface in some instances.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit db6e223. Configure here.}

[sentry]

Bug: getDynamicSamplingContext now uses SentrySdk::getClient(), which may return NoOpClient if a custom hub is used without updating the global client, breaking trace propagation.
_{Severity: HIGH}

Suggested Fix

To build the Dynamic Sampling Context, use the client from the current hub instead of the one from SentrySdk::getClient(). This ensures the correct client configuration is used, especially in multi-hub scenarios where the global client may not be the one associated with the current transaction.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/Tracing/Transaction.php#L93

Potential issue: The function `getDynamicSamplingContext()` was changed to use
`SentrySdk::getClient()` instead of the hub's client. `SentrySdk::getClient()` resolves
the client from the isolation or global scope, not the current hub. In scenarios where a
custom hub is set via `SentrySdk::setCurrentHub()` without also updating the global
client (e.g., in multi-tenant apps), `SentrySdk::getClient()` will return a
`NoOpClient`. This results in an incomplete Dynamic Sampling Context (DSC) missing
`public_key`, `release`, and `environment`, which breaks trace propagation between
services.

_{Did we get this right? 👍 / 👎 to inform future reviews.}