feat(cells): Add organization avatar to control silo

[lynnagara]

In order to support moving org listing endpoint to the control silo, we need avatar data available without crossing silo boundaries.

This change adds avatar_type and avatar_ident columns to sentry_organizationmapping so the control silo can easily serve the avatar data. The replication logic will be added as a follow up - this PR just contains the schema migration.

[github-actions]

This PR has a migration; here is the generated SQL for src/sentry/migrations/1068_add_avatar_to_organizationmapping.py

for 1068_add_avatar_to_organizationmapping in sentry

--
-- Add field avatar_ident to organizationmapping
--
ALTER TABLE "sentry_organizationmapping" ADD COLUMN "avatar_ident" varchar(32) DEFAULT NULL NULL;
--
-- Add field avatar_type to organizationmapping
--
ALTER TABLE "sentry_organizationmapping" ADD COLUMN "avatar_type" smallint DEFAULT 0 NOT NULL CHECK ("avatar_type" >= 0);

[markstory]

Having these fields here is convenient as we don't have more tables to manage, but it also means that upserts from cells are slightly more complicated as we have to read the avatar record and include it as well.

Another approach would be to separate the avatar into a dedicated replicated model. That would allow us to replicate state independently and have simpler logic to handle updates and deletes.

[lynnagara]

I think the upsert/delete implementation might be about the same either way as both ways would hook into the same two OrganizationAvatar functions - handle_async_replication and handle_async_deletion. With the orgmapping you get org deletion cascades for free, as well as the 1:1 relationship between avatar and orgs structurally enforced. Having said that HybridCloudForeignKey seems to handle that anyway so it's not really a big deal.

Separate table seems to more closely match patterns in the rest of the hybrid cloud codebase, so i switched this migration out to do it that way.

The new table contains the organization ID as the only hybrid cloud foreign key (it's already a snowflake id, so the only one guaranteed to be globally unique) with the unique=True constraint. The original primary key from the OrganizationAvatar model is not replicated to control as it is not guaranteed to be globally unique -- it's easier to base replication logic, etc, on the org id in this case.

[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 69b7b89. Configure here.}

[github-actions]

This PR has a migration; here is the generated SQL for src/sentry/migrations/1068_add_organization_avatar_replica.py

for 1068_add_organization_avatar_replica in sentry

--
-- Create model OrganizationAvatarReplica
--
CREATE TABLE "sentry_organizationavatarreplica" ("id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY, "organization_id" bigint NOT NULL UNIQUE, "avatar_type" smallint NOT NULL CHECK ("avatar_type" >= 0), "avatar_ident" varchar(32) NOT NULL);