test: stop asserting which of two equal deadlines won the RPC-02 race

The cleanup test sets `totalDeadlineMs` and `idleDeadlineMs` to the same
25ms and then asserted `RPC_TOTAL_DEADLINE_EXCEEDED`. Which of the two the
runtime reports depends on whether the clock had crossed the total
deadline by the time the idle wait expired, so under parallel load the
assertion was a coin flip — it passed alone and failed in a 27-file run.

A test that fails for a reason unrelated to its subject teaches a reader
to ignore it, which is the failure mode this whole review pass was about.
The subject here is that a throwing `return` accessor cannot replace the
outcome the runtime already selected and that cancellation still runs
exactly once, so the assertion now pins the terminal kind and accepts
either deadline code.

Confirmed by three consecutive 485-test runs of the same 27-file set that
previously reproduced the failure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tests/unit/browser-rpc/browser-rpc-remediation.test.ts

@@ -645,10 +645,17 @@ describe("RPC-01 only a positive receipt confirms physical closure", () => {
     );
 
     expect(results).toHaveLength(1);
-    expect(results[0]).toMatchObject({
-      ok: false,
-      error: { code: "RPC_TOTAL_DEADLINE_EXCEEDED" },
-    });
+    // The subject is that a throwing accessor cannot replace the outcome the
+    // runtime already selected, not which deadline won. `totalDeadlineMs` and
+    // `idleDeadlineMs` are deliberately equal here, so pinning one of the two
+    // timeout codes would make this assertion a coin flip under load.
+    expect(results[0]).toMatchObject({ ok: false });
+    const failure = results[0] as { error: { kind: string; code: string } };
+    expect(failure.error.kind).toBe("REQUEST_TIMEOUT");
+    expect([
+      "RPC_TOTAL_DEADLINE_EXCEEDED",
+      "RPC_STREAM_IDLE_TIMEOUT",
+    ]).toContain(failure.error.code);
     expect(cancels).toHaveLength(1);
   });