Provider synchronization and durable removal

Context

The accepted durable-removal origin does not approve every proposed synchronization change. The current suspension/reinstatement implementation returns provider trouble after one attempt; the proposed queue alignment remains open.

Acceptance is an explicit ordering exception, and its external credential effects are not atomic with token consumption.

Decision

Run invitation preparation and membership-removal provider work after commit, retain acceptance’s provider-before-activation exception, and propose durable suspension/reinstatement synchronization alongside the existing removal queue.

Alternatives Considered

Perform ordinary provider changes inside the database transaction. External provider effects survive rollback and can leave credentials without matching committed membership state.

Retain suspension as a single post-commit attempt. A failed synchronization leaves provider and membership state different without automatic repair, unlike durable removal work.

Consequences

Committed membership state is authoritative for fresh evaluation; provider synchronization follows its own failure path.

Acceptance prepares the credential first and consumes the invitation later, leaving a documented concurrent-password risk.

Making suspension and reinstatement durable remains a proposed implementation change, not current behavior.