Add forceCloudflareWorkers option to bypass runtime inference

[carl-wells-crowdhandler]

isCloudflareWorkers is now a function that consults a module-level override before falling back to the navigator.userAgent check. Callers that already know they're on Workers can set options.forceCloudflareWorkers: true on init() to skip inference and guarantee the fetch/await-recordPerformance code paths are used.

[luke-owen-crowdhandler]

@copilot

[luke-owen-crowdhandler]

@copilot Are you able to review this PR?

[Copilot]

@copilot Are you able to review this PR?

Sure, here's my review:

---

Overall: The approach is clean — converting isCloudflareWorkers from a module-level boolean to a function backed by a nullable override is a good pattern. The call-sites in BaseClient and Gatekeeper were updated correctly and the TypeScript types/JSDoc/dist are all in sync. A few things worth addressing:

---

🐛 Bug: module-level override is never reset between init() calls

cloudflareWorkersOverride in runtime.ts is module-level mutable state. Once init({ options: { forceCloudflareWorkers: true } }) has been called, every subsequent init() call in the same process — even without forceCloudflareWorkers — will still see isCloudflareWorkers() === true because nothing clears the override. This affects test suites and any scenario where init() is called more than once (e.g. unit tests, module re-use across environments).

Suggested fix in init.ts:

- if (config.options?.forceCloudflareWorkers === true) {
-   setCloudflareWorkersOverride(true);
- }
+ // Unconditionally sync the override so repeated init() calls don't bleed state.
+ setCloudflareWorkersOverride(
+   config.options?.forceCloudflareWorkers === true ? true : null
+ );

---

⚠️ Minor: getCloudflareWorkersOverride is exported from runtime.ts unnecessarily

getCloudflareWorkersOverride is exported and therefore appears in dist/types/common/runtime.d.ts, but it isn't re-exported from index.ts. It was introduced solely for the debug-log line inside init.ts. Unless you intend it to be a public API, making it unexported (or at minimum keeping it unexported from the main barrel) avoids accidentally locking in the internal implementation.

---

ℹ️ Suggestion: add unit tests for the new behaviour

The repo has Jest/ts-jest configured (npm test). A small test file covering:

• isCloudflareWorkers() returns true when the override is set via setCloudflareWorkersOverride(true)
• isCloudflareWorkers() falls back to navigator detection when the override is null
• Calling init() twice — once with forceCloudflareWorkers: true, once without — leaves isCloudflareWorkers() as false (i.e. the reset-on-each-call fix above)

…would give confidence this doesn't regress silently.