test(client): record the measured residual and the CI readings in the suites' headers

auth-rotated-session-token's first case is the card's whole probe; with
the cold start moved out, what its window holds is its own work, and the
header now says how that measured under load and where the lever is. The
two organization suites' headers quote their own first-case readings from
the red Test Core run instead of a claim about every other case.

Claude-Session: https://claude.ai/code/session_01UYBdGBzWSrAMzpW8ah3GbP
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

packages/client/src/auth-rotated-session-token.test.ts

@@ -65,6 +65,15 @@
 // the cost moved out, the `60_000`s are gone and every case runs on the
 // default `testTimeout`.
 //
+// ⚠ What a window holds now is behaviour, and ① holds the most: the card's
+// whole probe, a sign-up plus five more calls that each check a password or a
+// TOTP code. It takes about 700 ms on 4 vCPU with the box otherwise quiet, and
+// a warm-up that ran the WHOLE probe left it no faster than this one does, so
+// none of that is loading. Under sixteen CPU-bound busy loops it took 4.1-4.2
+// s. Under twenty-four, the load that times out every one of these suites'
+// cold first cases, it reached the 5000 ms budget on its own work. If CI ever
+// reds it, the lever is that case's own work, ⛔ not a timeout.
+//
 // ⛔ It shares nothing a case asserts on. Its engine and manager are its own
 // and are destroyed before any case starts. Every case still builds a fresh
 // engine, a fresh `AuthManager` and a fresh sign-up. What it leaves warm is

packages/client/src/organization-invitation-resend-team-placement.test.ts

@@ -65,9 +65,11 @@
  * `auth-login-register-envelope.test.ts`, which carries the same arrangement
  * and the same fix. Here, idle on 4 vCPU at `c74de10a9`, that cost put ① at
  * 1245 ms against 307-411 ms for the four later cases that run `arrange()`.
- * Under twenty-four CPU-bound busy loops, the load that reproduces CI's
- * failure in the sibling suites, ① timed out at vitest's 5000 ms
- * `testTimeout` while every other case passed.
+ * On the `Test Core` shard where a sibling suite went red (PR #20325's run),
+ * ① took 3599 ms here against 486-820 ms for the later cases that run
+ * `arrange()`. Under twenty-four CPU-bound busy loops on this box, the load
+ * that reproduces that red, ① timed out at vitest's 5000 ms `testTimeout` in
+ * every run.
  *
  * So the cost is now paid by a module-scope `await`, during COLLECTION, which
  * no vitest clock covers: `@vitest/runner@4.1.11` wraps hooks and test bodies

packages/client/src/organization-invite-role-default.test.ts

@@ -69,9 +69,11 @@
  * `auth-login-register-envelope.test.ts`, which carries the same arrangement
  * and the same fix. Here, idle on 4 vCPU at `c74de10a9`, that cost put ① at
  * 968 ms against 310-336 ms for ② and ③, which run the same `arrange()`.
- * Under twenty-four CPU-bound busy loops, the load that reproduces CI's
- * failure in the sibling suites, ① timed out at vitest's 5000 ms
- * `testTimeout` while every other case passed.
+ * On the `Test Core` shard where a sibling suite went red (PR #20325's run),
+ * ① took 2849 ms here against 497-820 ms for the later cases that run
+ * `arrange()`. Under twenty-four CPU-bound busy loops on this box, the load
+ * that reproduces that red, ① timed out at vitest's 5000 ms `testTimeout` in
+ * every run.
  *
  * So the cost is now paid by a module-scope `await`, during COLLECTION, which
  * no vitest clock covers: `@vitest/runner@4.1.11` wraps hooks and test bodies