Distinguish async vs sync database spans in APM (asyncpg vs SQLAlchemy)

### Problem Statement

Description:
Currently, Sentry groups all database spans under a generic db operation regardless of whether the underlying driver is async (e.g. asyncpg) or sync (e.g. SQLAlchemy). There is no span.op, attribute, or tag that differentiates the two at the span level.
Our stack:

FastAPI (async)
asyncpg (async DB driver)
SQLAlchemy (sync ORM in some services)

Some way to distinguish async from sync DB spans — either via span.op (e.g. db.async vs db.query), a span attribute like db.driver, or at minimum a tag indicating the driver being used.
Why it matters:
In async-first stacks (FastAPI + asyncpg), mixing async and sync DB operations can have real performance implications — connection pool contention, event loop blocking, etc. Without span-level differentiation, APM traces don't give enough signal to diagnose these issues effectively.
This came up directly when evaluating Sentry against ELK for our observability stack. ELK allows custom field-level filtering that makes this distinction trivial. Closing this gap would make Sentry's APM significantly more useful for async Python backends, which are increasingly the norm.

### Solution Brainstorm

_No response_

### Product Area

Performance

The issue names FastAPI, asyncpg, and SQLAlchemy but no repository files, tests, or entry points. Start by locating how database spans are created and labeled for these drivers, then resolve which span-level distinction is required and verify that async and sync database operations can be filtered separately.

Written by the indexing model from the issue text.