feat(messaging): let an install end (CHOO-2626)

[petr-sandbox]

Last of three stacked PRs splitting #435. Base is work/messaging-install-flow (PR B) — review A and B first; the diff shown here is only what C adds.

A and B build an install. This one takes it apart again, from either end: the operator disconnecting it, or Slack saying the app was removed. Until this lands an install is one-way, and the first customer who uninstalls leaves a live bot token in the database and a bridge posting into a workspace that has thrown it out.

An install can now end

status gains two terminal values beside active:

• disconnected — ended here, by someone who decided to.
• revoked — ended there: the platform told us the app was removed or its token killed.

They are distinct because an operator whose bridge stopped working needs to know whether it was news or a decision. The workspace uniqueness index now covers only active rows, so a workspace that has been disconnected can be installed again — by the same tenant or by another.

end() drops the encrypted token and the bridge pointer as it writes the status. A worthless credential still reads like a live one to whoever finds the dump; keeping the row is the record, keeping the secret is not part of it. Ending an install twice is success, because the two ways in can race.

The order things are destroyed in

Tell the platform first, then destroy: auth.revoke → end the row and commit → remove the bridge.

If Slack refuses for a reason we do not recognise, the install is left intact and retryable. The alternative — destroying the bridge first — leaves a live key in the next dump and nothing pointing at it to revoke.

The row before the bridge is not a preference. messaging_installs.bridge_id is a real foreign key with no ON DELETE, so the row has to let go before the bridge can be deleted at all. (ON DELETE SET NULL was considered and rejected: the constraint is composite, so a plain SET NULL would null tenant_id too, and column-scoped SET NULL (bridge_id) is Postgres 15+.) And if the deletion then fails, what is left is a bridge with no credential that an operator can see and remove, rather than an install still claiming a workspace it has been thrown out of. The lifecycle stub in the tests really deletes the row, so a caller that forgets to release the pointer fails here rather than in production.

A token Slack already considers dead — invalid_auth, token_revoked, account_inactive — is a success, not a failure.

Slack ending it

app_uninstalled and tokens_revoked are checked before resolve, not after, because the two disagree about what a missing bridge means: this is the one event that arrives as the bridge it would resolve to is going away.

One behaviour change comes with it. An event naming a workspace nobody has installed now answers 200 instead of 404. Slack cannot fix it — an app left in a workspace goes on posting for as long as someone leaves it there — and telling it repeatedly that its posts fail is held against the app as a whole.

Operator surface

GET /messaging-apps/installs and DELETE /messaging-apps/installs/{id}. The list includes ended installs deliberately: an operator looking at it is usually looking because something stopped working, and a list of only the live ones answers "there is nothing here" to the question "what happened to the one that was here yesterday". No token and nothing derived from one is in the response. There is no UI for it yet — that is the next piece of work.

Known follow-up

Disconnecting removes the bridge, which detaches its rooms to internal-only. Re-installing the same workspace builds a new bridge and does not reattach them. Preserving room links across a re-install needs a reattach path and is not in this PR.

Checks

just typecheck clean (255 files), just check clean, single alembic head a7f2c3e9b481, full suite green.

git diff work/multi-tenancy-phase4 work/messaging-install-lifecycle is empty — A+B+C reproduce #435 exactly.

Part of CHOO-2626. Stacked: A → B → C (this).

🤖 Generated with Claude Code