feat(scopes): use TransactionSampler

[Litarnus]

No description provided.

[sentry]

Bug: The Transaction constructor now defaults to the global hub instead of using the specific hub instance on which startTransaction() was called, affecting multi-hub scenarios.
_{Severity: MEDIUM}

Suggested Fix

The TransactionSampler::startTransaction method should be updated to accept the HubInterface instance as a parameter. This hub instance should then be passed explicitly to the Transaction constructor, restoring the previous behavior and ensuring the transaction is associated with the correct hub on which it was started.

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/TransactionSampler.php#L25

Potential issue: The refactoring of `TransactionSampler::startTransaction` to a static
method removed the passing of the `HubInterface` instance to the `Transaction`
constructor. Consequently, the constructor now defaults to using the global hub via
`SentrySdk::getCurrentHub()`. In scenarios where multiple hubs are instantiated and
used, calling `startTransaction()` on a specific, non-global hub will cause the
resulting transaction to be incorrectly associated with the global hub. This leads to
the transaction event being captured by the wrong hub and its Dynamic Sampling Context
(DSC) being populated from the wrong client's options, breaking the API contract for
multi-hub usage.

Also affects:

• src/State/Hub.php:239~239

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

[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 3b8b293. Configure here.}

[sentry]

Bug: In multi-hub scenarios, transactions are incorrectly associated with the global hub instead of the hub that created them, causing events to be sent to the wrong project.
_{Severity: HIGH}

Suggested Fix

The static TransactionSampler::startTransaction method should be modified to accept the calling HubInterface instance as an argument. This hub instance must then be passed to the Transaction constructor, like new Transaction($context, $hub), to ensure the transaction is correctly associated with the hub that initiated its creation.

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/TransactionSampler.php#L25

Potential issue: The refactoring of `Hub::startTransaction` to use the static
`TransactionSampler::startTransaction` method has introduced a regression. The call to
`new Transaction($context)` inside the sampler no longer receives the calling hub
instance. As a result, the `Transaction` constructor defaults to using the global hub
via `SentrySdk::getCurrentHub()`. In a multi-hub scenario, if a transaction is started
on a non-current hub, subsequent operations like `finish()` will be executed against the
wrong hub, causing events to be captured by the wrong client and sent to the incorrect
DSN.