Server: send each item at the revision its ciphertext is sealed at, keep team archiving with the owner, refuse suspended accounts, and stop enrolment failing after an hour

- Pull hydrated every historical change entry with the item's current ciphertext under that entry's
  old revision. The AAD binds the revision, so a client opened it at the wrong version, failed, and
  parked its own pending edit as undecryptable. Entries an item has since moved past are left out; the
  later entry carries the same payload under the right number, and a fresh device no longer downloads
  an item once per edit it ever had.
- Deleting a team's last vault archived the team whoever deleted it, so an admin could archive it out
  from under its owner. Only the owner's delete archives it now, and TeamService.ArchiveAsync checks.
- UserStatus was checked nowhere on the request path. ActiveAccountRequirement on both policies answers
  403 account-not-active for a suspended or deprovisioned account.
- The hourly last-seen update moves xmin under the tracked user, and enrolment then saved that user
  against the stale token: a 500 for anybody enrolling more than an hour after first signing in. The
  entity is reloaded after the update.

src/DodoSSH.Api/Authorization/CurrentUserContext.cs

@@ -102,8 +102,14 @@ internal sealed class CurrentUserContext(
     /// read-then-write: <c>user_account</c> carries the xmin concurrency token, so two overlapping
     /// requests from one user would each read the row, each set the timestamp, and the second would
     /// fail on a version that had moved under it. This writes at most one row and cannot conflict.
-    /// The tracked entity is deliberately left alone — a value up to an hour stale in memory changes
-    /// nothing, and marking it modified would enlist the user row in whatever the request saves next.
+    /// <para>
+    /// ◆ <b>But the write moves xmin under the tracked entity, so the entity is re-read after it.</b> It is
+    /// not marked modified — that would enlist the user row in whatever the request saves next — and a
+    /// stale timestamp in memory would change nothing on its own. A stale concurrency token does: the next
+    /// save in the same request that touches this user (enrolment stamps <c>EnrolledAtUtc</c>) compared
+    /// against the version from before the update and failed, so enrolling more than an hour after first
+    /// signing in answered 500. Only when a row was actually written, which is once an hour at most.
+    /// </para>
     /// </remarks>
     private async Task RefreshLastSeenAsync(UserAccount user, CancellationToken cancellationToken)
     {
@@ -114,13 +120,18 @@ internal sealed class CurrentUserContext(
             return;
         }
 
-        await database.Users
+        var written = await database.Users
             .Where(u => u.Id == user.Id
                 && (u.LastSeenAtUtc == null || u.LastSeenAtUtc < now - LastSeenWindow))
             .ExecuteUpdateAsync(
                 setters => setters.SetProperty(u => u.LastSeenAtUtc, now),
                 cancellationToken)
             .ConfigureAwait(false);
+
+        if (written > 0)
+        {
+            await database.Entry(user).ReloadAsync(cancellationToken).ConfigureAwait(false);
+        }
     }
 
     private Task<UserAccount?> FindAsync(string issuer, string subject, CancellationToken cancellationToken) =>