Review findings on rustfs#7195: the receive-side staleness gate compared a
source `updatedAt` against a stamp the local write had put on the record,
and the verdict, the write and the deletion mark were three separate steps.
- IAM writes gain explicit-stamp variants (`set_policy_at`, `policy_db_set_at`,
group and user `*_at`, `new_service_account_at`, `update_service_account_at`)
so a replicated record carries its source time; local edits are unchanged.
- `apply_iam_item` runs verdict, write and mark commit under the
site-replication state transaction (distributed state-object lock), so a
concurrent older grant and newer revoke are ordered on every node.
- A replicated service account is created with its source status in one
write (`NewServiceAccountOpts::status`), never enabled transiently.
- Deletion marks are pruned by age (30 days) instead of by count.
- Bucket-config deletes persist the source stamp (`delete_if_incarnation_at`).
Regressions run through the real receiver: delayed in-order updates for every
gated item type, concurrent grant/revoke, delete then stale re-create, disabled
service-account create, delete stamping in ecstore, and mark retention.
唐小鸭
10575e851a