flake: createThenBindOrRebind fails intermittently in full-suite CI (not in isolation)

[sahrizvi]

What

test/altimate/workspace/create-then-rebind.test.ts:115 — CLI: createThenBindOrRebind > unlinked project uses the atomic create-and-bind, and never rebinds — fails intermittently in CI's TypeScript job (OPENCODE_SKIP_SUBPROCESS=1 bun test --timeout 90000, full unsharded suite), but passes 100% reliably when run in isolation or alongside the rest of test/altimate/workspace/.

Failure:

110 |         body: { datamate: { id: 7, name: "proj" }, binding: BINDING, manage_url: "https://x.test/w/7" },
111 |       },
112 |     ]
113 |     await createThenBindOrRebind(IDENTIFIER, "proj", "/tmp/proj", null)
114 |
115 |     expect(sequence()).toEqual(["POST /datamate-project-bindings/"])
                             ^
error: expect(received).toEqual(expected)

  [
+   "GET /datamate-project-bindings/by-path",
    "POST /datamate-project-bindings/",
  ]

- Expected  - 0
+ Received  + 1

The test passes null for the "existing binding" argument (explicitly "unlinked project"), so createThenBindOrRebind should go straight to the atomic POST — it should never issue a GET .../by-path lookup first. The extra GET only appears in the full-suite run, which points at shared/module-level state (likely a binding-resolution cache in packages/opencode/src/cli/cmd/link.ts) picking up something from another test file that runs earlier in the full suite, not properly isolated per-test.

Evidence from PR #1362 (v0.12.3 release PR)

Observed across 4 CI runs of the same PR, with only unrelated commits (an unrelated marker fix, a changelog commit) landing between them:

Run	Result
1	FAIL (this test)
2	PASS
3	FAIL (same assertion, same test)
4 (manual re-run, no code change)	FAIL (same assertion, same test)

None of the commits between runs touched cli/cmd/link.ts, plugin/tui/altimate/workspace.tsx, or any binding/cache code — ruling out that PR's content as the cause.

Repro

Does NOT reproduce locally:

cd packages/opencode
OPENCODE_SKIP_SUBPROCESS=1 bun test --timeout 90000 test/altimate/workspace/
# 693 pass, 0 fail

Reproduces only in CI's full, unsharded bun test --timeout 90000 run (no file filter) — worth trying to reproduce with the exact same invocation, matching CI's runner resource constraints, before assuming which other test file is the polluter.

Suggested next step

Find the module-level cache/singleton in cli/cmd/link.ts (or wherever the binding-resolution lookup lives) that isn't reset between test files, and either give it a test-only reset hook or scope its key more tightly so cross-file resolutions can't bleed into an unrelated test's expected call sequence.

Not a release blocker — TypeScript is not a required branch-protection status check on main, and this test's file is untouched by any release changes. Filed during the v0.12.3 release so it doesn't get lost in a transcript nobody rereads.