fix(iam): replicate a service account as the record that is stored

Site replication sent an edit of a service account as the fields the
request changed. A peer orders the items of an account by revision and
drops an older one, which is right for a whole account and loses data for
a part of one: when an edit did not reach a peer, or reached it after a
later edit, the peer kept the old secret key, status or inline policy
under the revision of the later edit, and healing took the sites for
equal. Two requests at one site sufficed, as the sender dropped the item
of the first when the second was already stored.

The first sync of a new site, healing and IAM export put an account
together from two places: the revision from storage, and the claims and
the inline policy from the cache of the server; healing took the secret
key and the status from the cache as well. A server whose cache had not
heard of an edit made through another server sent the account from
before the edit under the revision of the edit, and a peer kept that.

replicationItem now sends a create or an edit as the account stored at
that time: the whole record, read once, with its revision, as it does
for a group. serviceAccountSnapshot builds it from the record and the
token in it; IAM export uses the same function, and sync, heal and the
update handler only name the account. The wire types and the way a peer
applies an item do not change: a peer on 20261109 or 20261026 takes such
an edit as it takes a healed account, which also means that it keeps the
inline policy on an edit that names none. A site that is not upgraded
still sends its edits as before.

The hook reads what it sends before it takes the lock of the replication
configuration: loading an identity takes that lock for reading, and a
read lock asked for again behind a waiting writer is never granted. An
account whose stored token cannot be read is an error, as it was for sync
and heal, and is not taken for deleted.

A new service account of a user that was deleted and created again now
reaches the peers without waiting for healing: the create carries the
claims of the token, among them the parent revocation a peer asks for.

An edit gives every site the whole account of the site that took it.
Accounts that already differ between sites under one revision are not
repaired by this change, only by their next edit.

Signed-off-by: Feng Ruohang <rh@vonng.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

CHANGELOG.md

@@ -25,10 +25,30 @@
   In the Console, clearing the policy editor of an access key no longer removes
   the policy; enter `{}` to remove it. The fix does not bring back a policy
   that was removed, and a site of a replicated deployment that does not run the
-  fix still removes the policy when such an edit reaches it, so sites can
-  differ. Upgrade every site, then review on each site the accounts that
-  `svcacct info` reports with `Policy: implied`, and set the policy again on
-  those that were meant to be restricted.
+  fix still removes the policy on such an edit that it takes itself or receives
+  from another site that does not run it, so sites can differ. Upgrade every
+  site, then review on each site the accounts that `svcacct info` reports with
+  `Policy: implied`, and set the policy again on those that were meant to be
+  restricted.
+- Site replication sends a service account or access key as the record its
+  site has stored, whole: for a create, for every edit, at the first sync of a
+  new site and when healing. IAM export writes that record too. Until now an
+  edit was sent as the fields it changed. A peer that an earlier edit had not
+  reached, or reached late, kept the old secret key, status or inline policy
+  under the revision of the later edit, and healing took the sites for equal:
+  a key that was rotated, disabled or restricted on one site stayed as it was
+  on the other. Sync, heal and export took the claims and the inline policy, and
+  heal the secret key and status as well, from the cache of the server that ran
+  them, which can predate an edit made through another server of the site, and
+  sent them under the revision of the stored record. A service account created
+  for a user that had been deleted and created again did not reach the peers
+  before healing. Peers on 20261109 and 20261026 apply the new items as they
+  apply a healed account, and an edit that names no policy no longer removes the
+  inline policy on such a peer; a site that is not upgraded still sends its own
+  edits the old way. An edit now gives every site the whole account of the site
+  that took it, so accounts that already differ between sites are not repaired
+  by the upgrade, but by the next edit: after upgrading every site, review such
+  accounts and edit each one at a site that has it right.
 
 ## RELEASE.2026-11-09T00-00-00Z