Ensure SDK-captured error events have a proper `mechanism`

[Lms24]

Description

When Sentry SDKs capture errors (e.g. via captureException), they include a mechanism field on the captured exception(s). Among other metadata, the mechanism most importantly contains the following properties:

• handled: boolean: a boolean indicating if the captured exception was handled by users or not. (this is a hard/impossible decision sometimes, so we rather tend to false in cases where we don't know. The limitations around this are another topic and out of scope for this issue)
• type: string: an identifier which mechanism (or part of the SDK) captured the error.

By default, e.g. if users call captureException, the mechanism defaults to:

{
  handled: true,
  type: 'generic'
}

However, ideally, our SDK instrumentation sets a custom mechanism for automatically captured errors, depending on which instrumentation or part of the SDK captured the error. For example:

captureException(error, {
  mechanism: {
    handled: false,
    type: 'solidstart',
  },
});

Unfortunately, we don't do this consistently across all SDKs, integrations or generally places where we call captureException. We should change this and align on always setting handled and type.

type naming pattern:

• should align with sentry.origin (aka Trace Origin) as much as possible (e.g. whenever we capture within a specific span).
• if N/A directly, make sure naming pattern follows trace origin definition

For now, some general todos:

• align on a pattern what to set as type
• add type and handled to every captureException call where they're currently missing
• update develop docs with better wording/examples and that SDKs should always set these properties

[linear]

JS-788 Ensure SDK-captured error events have a proper `mechanism`