ref(db): Replace create_or_update with update_or_create in Buffer.process

[vgrozdanic]

Buffer.process had one remaining caller of Sentry's legacy create_or_update in the elif model: branch — the path taken for non-Group models like ReleaseProject, ReleaseProjectEnvironment, GroupTombstone, and GroupRelease.

A simple update_or_create doesn't work here because update_kwargs is built from F() increment expressions (F("new_groups") + 1). Django evaluates defaults on both the UPDATE and INSERT paths, and F-expressions fail on INSERT since there is no existing row to resolve against. This is what caused the original migration attempt (reverted in #97840) to fail.

Instead this PR uses the explicit pattern: filter().update() first; if no rows were affected, create() with raw column values inside a savepoint, retrying as a plain update on IntegrityError in case a concurrent worker inserts between the two steps. All models that reach this branch have unique constraints on their filter fields, so the create-with-retry pattern is safe.

Regression tests added for the update path (F() increment applied, buffer_incr_complete signal fires with created=False), the create path (initial value set, signal fires with created=True), and the race-condition path (IntegrityError on create is swallowed, no exception propagates). Also removes the stale create_or_update mock from test_signal_only and removes src/sentry/buffer/base.py from the allowlist.

Part of the broader create_or_update deprecation tracked in the repo.

[sentry-warden]

extra fields silently dropped on INSERT path in Buffer.process

In the elif model: rollout branch, when filter().update() matches no rows and a new record is created, create_kwargs is built from filters and columns only — extra is omitted. The legacy create_or_update it replaces did include extra on the INSERT path (it resolved both F-expressions and plain values from values/defaults into create_kwargs). As a result, caller-supplied fields like last_seen are silently dropped on creation and fall back to model defaults. The create branch only fires when the filtered row is absent (e.g. a GroupTombstone/GroupRelease row deleted between the buffer enqueue and flush), so this is a narrow correctness regression rather than a crash.

Evidence

• create_or_update in db/models/query.py builds create_kwargs from kwargs plus iterating values.items() and defaults.items(), so non-F extra values (e.g. last_seen) were written on INSERT.
• The new branch in buffer/base.py sets create_kwargs = {**filters, **{col: v for col, v in columns.items()}}, omitting extra, so last_seen is not passed to model.objects.create().
• GroupTombstone caller in event_manager.py:320-331 passes extra={'last_seen': max(event.datetime, group_tombstone.last_seen)}; if the tombstone row is gone at flush time the create path fires and last_seen falls back to auto_now_add.
• ReleaseProject/ReleaseProjectEnvironment callers pass no extra, and GroupRelease filters by an existing id, so the create path with extra is only reached on a deletion race — limiting real-world impact.

_{Identified by Warden sentry-backend-bugs · C5Q-Q33}