E2E group-chat specs leak a conversation per test: 1,909 orphan rows on production, 0 messages

[TortoiseWolfe]

The finding

conversations on production held 1,910 rows for 20 users. 1,909 of them were E2E
artifacts:

is_group = true                    1909
distinct participants                 2   (scripthammer.e2e+test-primary@,
                                            scripthammer.e2e+test-tertiary@)
group_name  "Grp N"                 698
            "Test Group N"          687
            "iso-group-N"           524
messages / group_keys / conversation_members    0 / 0 / 0

Exactly one genuine 1:1 conversation existed, and it has no messages either.

Created Jul 25 – Aug 5, tracking CI activity, peaking at 157 on Aug 5 — the day the
project hit its quota ceiling.

Why it matters

The group-chat specs create a conversation per test and never tear it down, so every CI
run left roughly two dozen behind permanently. Each row is published to realtime,
which bears directly on the exceed_realtime_message_count_quota violation in #567 —
alongside egress and MAU.

This is not a tidiness issue. It is unbounded growth in a production table driven
entirely by CI, with no upper limit and no cleanup.

Current state

Purged from the new project (org migration, #567): 1,909 group rows deleted, the single
1:1 conversation retained, 0 messages affected. The leak itself is still in the specs,
so the new project starts accumulating again the moment E2E runs against it.

Fix

Tear-down in the group-chat specs — whatever creates a conversation deletes it. Note
cleanupOldMessages already runs in beforeAll across the messaging specs but only
targets messages, not the conversations themselves.

Second argument for #575: on a per-runner ephemeral database the litter dies with
the runner and no tear-down is needed at all.

Acceptance

• Run the group-chat suite twice and assert conversations returns to its starting
  count. Asserting "the suite passes" says nothing — it passed every time while
  leaking.