Host access lifecycle callbacks for revoking external credentials #2375

Problem

A host that keeps external credentials per member (for example keys an app issued on someone's behalf) has no way to revoke them when that member loses access to an app. Access changes on several paths: app sharing (shareApp), group create/update/delete, removing or leaving an organization, deleting an app, removing an organization and deleting a user. Each commits on its own, so a host can only find out afterwards, and the person keeps working credentials until something notices.

Proposal

Optional host access lifecycle callbacks, next to the existing resource lifecycle hooks:

• appAccessChanged({ organization, apps? }): after the sharing or group writes, inside the writing transaction, with that transaction's SQL client.
• memberRemoving({ organization, member }): before a membership is deleted, by removal or leave.
• appRemoving(app), organizationRemoving(organization), userDeleting(user): before the irreversible delete.

A failed callback refuses the change, so the person can retry. Hosts without callbacks keep today's behavior. Product-specific queries (who can use which app now) and any outbound calls stay in the host's implementation, outside the generic seam.

Two notes for implementers: external calls inside a transaction must be bounded and retry-safe, and an acknowledged external revocation can't be undone if the database transaction later rolls back, so revocation should be idempotent and a rolled-back removal should be able to recover.

Prior art

We carry this today as a patch in a public downstream deployment: https://github.com/JustYannicc/basalt/blob/main/patches/0018-pool-access-hook.patch (the generic part is HostAccessLifecycle in packages/sdk/src/contracts/executor.ts and apps/hosted/server/src/contracts/access-lifecycle.ts, wired into resource-access.ts, groups.ts, the app-removal lifecycle, organization removal and the cloud auth hooks). Happy to turn the generic part into a PR if the shape works for you.