fix: Disable event processor background flush timers for edge clients

[keelerm84]

Summary

The Fastly Compute SDK creates a new LDClient per request and never calls close(). Because sendEvents defaults on, a real EventProcessor is constructed and its start() creates setInterval flush timers (the event flush timer and the context-deduplication flush timer). Those are cleared only by EventProcessor.close(), which the SDK and its example never call, so the timers keep the runtime event loop alive and root the whole client graph in memory -- a leak for a per-request client. (This is also what caused jest to hang without --forceExit.)

A background flush timer is not a viable delivery mechanism on Fastly Compute anyway: outbound requests must be made while a request is being handled, and by default each request runs in a fresh sandbox that is torn down afterward. The supported pattern is to flush explicitly with event.waitUntil(client.flush()), which the SDK already documents and the example already uses.

Changes

• Add an opt-in internal option disableBackgroundEventFlush (LDInternalOptions), threaded through LDClientImpl's FDv1 and FDv2 construction into the EventProcessor's existing start parameter. It defaults to true when the option is unset, so behavior is unchanged for the Node server SDK and every other consumer.
• Set disableBackgroundEventFlush: true in the Fastly edge client.
• Document the per-request client lifecycle and event-flushing model in the README, including the reusable-sandboxes caveat (don't module-scope a client and rely on it to self-flush).
• Add a test asserting the edge client constructs the event processor with start = false.

flush() and sendEvent() do not depend on start() having run (they only use constructor-initialized state; sdk-client already constructs the processor with start = false), so events are still recorded and delivered via explicit flush().

Part of the Fastly refresh epic (SDK-2643). Fixes SDK-2645.

---

Note

Medium Risk
Touches shared LDClientImpl event-processor construction for all server SDKs, though default behavior is preserved unless edge SDKs opt in.

Overview
Per-request Fastly clients were starting the shared EventProcessor background interval timers without ever calling close(), which kept the runtime alive and pinned the client in memory. This change adds an internal disableBackgroundEventFlush flag on ServerInternalOptions, wires it through LDClientImpl (FDv1/FDv2) into the existing EventProcessor start parameter, and enables it for the Fastly LDClient.

Node and other server SDKs are unchanged when the option is unset (startEventProcessor stays true). Events still buffer and ship via explicit flush() / sendEvent() without background timers.

The Fastly README now documents per-request init(), event.waitUntil(ldClient.flush()), and why module-scoped clients are unsafe with reusable sandboxes. A unit test asserts the edge client passes start = false to EventProcessor.

^{Reviewed by Cursor Bugbot for commit 9040b23. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

@launchdarkly/js-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 26365 bytes
Compressed size limit: 29000
Uncompressed size: 129044 bytes

[github-actions]

@launchdarkly/js-client-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 38747 bytes
Compressed size limit: 39000
Uncompressed size: 212249 bytes

[github-actions]

@launchdarkly/js-client-sdk size report
This is the brotli compressed size of the ESM build.
Compressed size: 32027 bytes
Compressed size limit: 34000
Uncompressed size: 114248 bytes

[github-actions]

@launchdarkly/browser size report
This is the brotli compressed size of the ESM build.
Compressed size: 179504 bytes
Compressed size limit: 200000
Uncompressed size: 831427 bytes

[joker23]

Since this is specific to edge sdks, I think putting this option in packages/shared/sdk-server/src/options/ServerInternalOptions.ts is more appropriate.