WebExtensions and Firefox e10s: which APIs are actually reachable from a content process?

I am porting a WebExtension (manifest v2) that needs to interact with page content across Firefox's multiprocess (e10s) architecture, targeting Firefox 120 and later. The extension currently assumes it can reach certain browser-level objects from code that now runs in an isolated content process, and I need to decide which parts of the design must move to a background script versus a content script before committing to a refactor.

The constraint is that e10s process isolation appears to restrict some APIs that older single-process extensions relied on, such as direct access to chrome window objects, while the documented WebExtensions API surface is described as stable. It is unclear to me where exactly the boundary falls: which calls are silently unavailable or behave differently when invoked from a content process, and whether this differs between release and nightly builds.

I can verify process separation in about:processes, but I lack a reliable way to map a given API call to the process context it is permitted in.

Which WebExtensions APIs are documented as background-only versus content-script-safe under e10s? Is there a supported way to detect at runtime which process context my code is executing in? Should I design against manifest v2 constraints now or plan for v3 migration given the published deprecation schedule?