A real 410 macOS received now replays as step 12,
since a token for another login gets refused as well.
Both Apple clients relisted and fetched only what they lacked,
so the README drops the note that no one had tracked.

Assisted-by: Claude Opus 5 via Claude Code
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

diff --git a/test/fixtures/macos-exchange/12-report-sync-collection-stale-token/request b/test/fixtures/macos-exchange/12-report-sync-collection-stale-token/request
new file mode 100644
index 0000000..4bd2ab2
--- /dev/null
+++ b/test/fixtures/macos-exchange/12-report-sync-collection-stale-token/request
@@ -0,0 +1,15 @@
+REPORT /dav/addressbook/ HTTP/1.1
+Brief: t
+Content-Type: text/xml
+Depth: 1
+Prefer: return=minimal
+
+<?xml version="1.0" encoding="UTF-8"?>
+<A:sync-collection xmlns:A="DAV:">
+  <A:sync-token>http://pro-tacts/sync/23/e0905a26346930c6</A:sync-token>
+  <A:sync-level>1</A:sync-level>
+  <A:prop>
+    <A:getetag/>
+  </A:prop>
+</A:sync-collection>
+
diff --git a/test/fixtures/macos-exchange/12-report-sync-collection-stale-token/response b/test/fixtures/macos-exchange/12-report-sync-collection-stale-token/response
new file mode 100644
index 0000000..55e4357
--- /dev/null
+++ b/test/fixtures/macos-exchange/12-report-sync-collection-stale-token/response
@@ -0,0 +1,7 @@
+410
+Content-Type: text/xml
+
+<?xml version="1.0" encoding="UTF-8"?>
+<d:error xmlns:d="DAV:">
+  <d:valid-sync-token/>
+</d:error>
diff --git a/test/fixtures/macos-exchange/README.md b/test/fixtures/macos-exchange/README.md
index 87abba6..5b5cbca 100644
--- a/test/fixtures/macos-exchange/README.md
+++ b/test/fixtures/macos-exchange/README.md
@@ -34,7 +34,20 @@ Step 08's request carries `http://pro-tacts/sync/1`, a token from before
 tokens named the book they were issued for
 (`docs/plans/2026-09-12-per-user-books.md`). The replay answers it with
 410 and `DAV:valid-sync-token` rather than the 207 delta the recorded
-session received. What macOS does after a 410 has not been recorded.
+session received.
+
+Step 12 is a 410 the client really received, captured 2026-09-16 under
+`rake dev` with the dev login switched so the token's digest named
+another login's book. Its replay refuses it for the same reason: the
+digest is not the replay login's. After the 410, macOS sent a ctag
+PROPFIND, the Depth 1 listing, a GET for the one card it lacked, the
+bootstrap PROPFIND, and a sync-collection report with the fresh token.
+The listing and bootstrap match steps 06 and 09 byte for byte, and the
+ctag PROPFIND differs from step 05 only in spelling CalendarServer
+`C:` rather than `D:`, so none of them were promoted. iOS (26.6.2) sent
+the same report apart from the token, took the same 410, and followed it
+with a ctag PROPFIND, the listing, and a multiget for the card it lacked,
+so `../ios-exchange` holds no step for it.
 
 ## The PUT steps