### Description

Removing the Check CI Config step altogether as well as associated parts
of the toxgen script (`fail_on_changes`). Added a BIG ALL CAPS WARNING
to `tox.ini` instead. Also updated the toxgen readme a bit.

Removing the check should be fine because we haven't actually seen cases
of people trying to edit `tox.ini` directly -- if this happens in the
future it's easy to notice in the PR. If we don't notice it then, we can
notice it during the weekly toxgen update. And if don't notice it then,
the file simply gets overwritten. 🤷🏻‍♀️


### The Problem With Checking `tox.ini`: The Long Read

In order to check manual changes to `tox.ini` on a PR, we hash the
committed file, then run toxgen, hash the result, and compare. If the
hashes differ, we fail the check. This works fine as long as there have
been no new releases between the two points in time when `tox.ini` was
last committed and when we ran the check.

This is usually not the case. There are new releases all the time. When
we then rerun toxgen, the resulting `tox.ini` is different from the
committed one because it contains the new releases. So the hashes are
different without any manual changes to the file.

One solution to this is always saving the timestamp of the last time
`tox.ini` was generated, and then when rerunning toxgen for the purposes
of the check, ignoring all new releases past the timestamp. This means
any changes we detect were actually made by the user.

However, the explicit timestamp is prone to merge conflicts. Anytime
`master` has had a toxgen update, and a PR is made that also ran toxgen,
the PR will have a merge conflict on the timestamp field that needs to
be sorted out manually. This is annoying and unnecessary.

(An attempt was made to use an implicit timestamp instead in the form of
the commit timestamp, but this doesn't work since we squash commits on
master, so the timestamp of the last commit that touched `tox.ini` is
actually much later than the change was made. There are also other
problems, like someone running toxgen but committing the change much
later, etc.)

### Solutions considered
- using a custom merge driver to resolve the timestamp conflict
automatically (doesn't work on GH PRs)
- running toxgen in CI on each PR and committing the change (would work
but we're essentially already doing this with the cron job every week)
- not checking in `tox.ini` at all, but running toxgen on each PR
(introduces new package releases unrelated to the PR, no test setup
committed -- contributors and package index maintainers also need to run
our tests)
- finding a different commit to use as the implicit timestamp (doesn't
work because we squash commits on `master`)
- ...

In the end I decided to just get rid of the check. If people modifying
`tox.ini` manually becomes a problem, we can deal with it then. I've
added a big warning to `tox.ini` to discourage this.



#### Issues
Closes #4886

#### Reminders
- Please add tests to validate your changes, and lint your code using
`tox -e linters`.
- Add GH Issue ID _&_ Linear ID (if applicable)
- PR title should use [conventional
commit](https://develop.sentry.dev/engineering-practices/commit-messages/#type)
style (`feat:`, `fix:`, `ref:`, `meta:`)
- For external contributors:
[CONTRIBUTING.md](https://github.com/getsentry/sentry-python/blob/master/CONTRIBUTING.md),
[Sentry SDK development docs](https://develop.sentry.dev/sdk/), [Discord
community](https://discord.gg/Ww9hbqr)

- Add a constant that contains the allowed message roles according to
OTEL and a mapping
- Apply that mapping to all gen_ai integrations
- We will track input roles that do not conform to expectations via a
Sentry issue in agent monitoring to make sure we continually update the
mappings
---------

Co-authored-by: Ivana Kellyer <ivana.kellyer@sentry.io>

Automatically fork isolation and current scopes when running tasks with
`concurrent.future`. Packages the implementation from
#4508 (comment)
as an integration.

Closes #4565

---------

Co-authored-by: Anton Pirker <anton.pirker@sentry.io>

### Description
Python 3.14 is out, let's use it for linting.

#### Issues
Ref #4895

#### Reminders
- Please add tests to validate your changes, and lint your code using
`tox -e linters`.
- Add GH Issue ID _&_ Linear ID (if applicable)
- PR title should use [conventional
commit](https://develop.sentry.dev/engineering-practices/commit-messages/#type)
style (`feat:`, `fix:`, `ref:`, `meta:`)
- For external contributors:
[CONTRIBUTING.md](https://github.com/getsentry/sentry-python/blob/master/CONTRIBUTING.md),
[Sentry SDK development docs](https://develop.sentry.dev/sdk/), [Discord
community](https://discord.gg/Ww9hbqr)

### Description
Remove old metrics code to make way for
#4898

Metrics was always an experimental feature and Sentry stopped accepting
metrics a year ago.

#### Issues
<!--
* resolves: #1234
* resolves: LIN-1234
-->

#### Reminders
- Please add tests to validate your changes, and lint your code using
`tox -e linters`.
- Add GH Issue ID _&_ Linear ID (if applicable)
- PR title should use [conventional
commit](https://develop.sentry.dev/engineering-practices/commit-messages/#type)
style (`feat:`, `fix:`, `ref:`, `meta:`)
- For external contributors:
[CONTRIBUTING.md](https://github.com/getsentry/sentry-python/blob/master/CONTRIBUTING.md),
[Sentry SDK development docs](https://develop.sentry.dev/sdk/), [Discord
community](https://discord.gg/Ww9hbqr)

### Description
Logs are not experimental anymore, but one of the internal log-related
functions still had "experimental" in the name.

#### Issues
<!--
* resolves: #1234
* resolves: LIN-1234
-->

#### Reminders
- Please add tests to validate your changes, and lint your code using
`tox -e linters`.
- Add GH Issue ID _&_ Linear ID (if applicable)
- PR title should use [conventional
commit](https://develop.sentry.dev/engineering-practices/commit-messages/#type)
style (`feat:`, `fix:`, `ref:`, `meta:`)
- For external contributors:
[CONTRIBUTING.md](https://github.com/getsentry/sentry-python/blob/master/CONTRIBUTING.md),
[Sentry SDK development docs](https://develop.sentry.dev/sdk/), [Discord
community](https://discord.gg/Ww9hbqr)

### Summary
Similar to getsentry/sentry-javascript#17883,
this allows the py sdk to send in new trace metric protocol items,
although this code is experimental since the schema may still change.
Most of this code has been copied from logs (eg. log batcher -> metrics
batcher) in order to dogfood, once we're more sure of our approach we
can refactor.

Closes LOGS-367

---------

Co-authored-by: Ivana Kellyer <ivana.kellyer@sentry.io>