carlos / platform Public

Pre-existing, found by the Opus review of mail-events-push, which makes it matter more. Not changed on that branch because it's the instances code's rule to decide.

The guard. apiinstances.go ~620–633 refuses a member-written manifest that pins a host at a sibling app's apex (<other-app>.<sqid>.<AppsDomain>), because the domains pass would then skip minting the sibling's own apex for ever (byHost). It decides "is this label another claimed app" with HasAppIn, which counts only live rows (deleted_at = 0).

The hole.

1. App A is trashed. Its name is still reserved until purge, but HasAppIn no longer sees it.
2. App B, with its own app-scoped token, writes a manifest with an instance at a.<sqid>.<AppsDomain>. The guard lets it through.
3. A is restored. Per the guard's own comment, the domains pass now skips A's apex — B holds it.
4. Anything addressed to A's platform host reaches B.

Why it now matters more. carlos email events push POSTs recipient addresses to https://<app>.<sqid>.<AppsDomain><path>. The push checks the app is live (so nothing goes out while A is trashed), but after step 3 A is live again and its events — guests' email addresses — go to B's instance.

Suggested fix. Have the sibling check count trashed rows too (HasAppIn → a query without the deleted_at = 0 filter, or HasAppIn || HasTrashedAppIn), since a trashed name stays reserved until purge — the same reading CreateAppIn and RenameAppIn already give it. Within one account, but across the app-scoped credential boundary.

Suggest this is settled before events push is turned on for anyone.