[APPS-2792] Add: harden the in-process local execution path

[tyffical]

Motivation

• Part of APPS-2792 — local Node execution for App Builder backend functions. Milestone 1 in the Kickoff doc, stacked on Milestone 0 ([APPS-2792] Add: in-process local execution for backend functions #479).
• [APPS-2792] Add: in-process local execution for backend functions #479 shipped the direct-import in-process execution mechanism itself but explicitly deferred hardening (both tracked as follow-ups in its own Out of Scope table). This PR adds it.
• The single biggest correctness risk of running backend functions in-process (vs. production's fresh-Deno-subprocess-per-execution model): @datadog/action-catalog's setExecuteActionImplementation and @datadog/apps-backend's setBackend both register runtime context via a shared, module-level setter. Without serialization, a second concurrent execution's registration could silently redirect the first's still-in-flight typed-import calls to the wrong identity — with no error at all. See the RFC's Decisions and Trade-Offs.

Changes

What changed	File
Local executions are now serialized via a promise-chain queue (enqueue) — never run concurrently. A rejected execution doesn't wedge the queue for whatever's next.	local-execution.ts
A returned result is now checked for JSON-serializability before being handed back — a circular reference or BigInt gets a clear, attributed error instead of an opaque downstream JSON.stringify failure; a bare function/Symbol (which JSON.stringify silently drops instead of throwing) is also caught explicitly.	local-execution.ts
New tests: two concurrent executions never interleave (proven via a shared globalThis order marker, not a mock); the queue keeps flowing after an earlier execution rejects; a loadModule rejection (simulating a native-module load failure) rejects cleanly; all three non-serializable-result shapes; the no-token-exposure and $.Source invariants from #479 are re-verified against the queued path.	local-execution.test.ts

QA Instructions

yarn install

yarn test:unit packages/plugins/apps/src/vite/local-execution.test.ts
# Expected: Test Suites: 1 passed / Tests: 20 passed ✅ VERIFIED

yarn test:unit packages/plugins/apps
# Expected: Test Suites: 23 passed / Tests: 305 passed ✅ VERIFIED

yarn workspace @dd/apps-plugin run typecheck
# Expected: no output, clean exit ✅ VERIFIED

npx eslint packages/plugins/apps/src/vite/local-execution.ts packages/plugins/apps/src/vite/local-execution.test.ts --quiet
# Expected: no output, clean exit ✅ VERIFIED

No manual local/staging QA for this PR specifically, same reasoning as #479: this module still isn't wired into createDevServerMiddleware (that's Milestone 2, stacked next as #481), so there's no npm run dev request path that reaches it yet.

Blast Radius

• No behavior change for any currently-shipping code path: local-execution.ts still isn't called from anywhere in the existing dev server.
• Risk: low. All changes are additive/internal to a module with no external callers yet; full existing test suite (305 tests) passes.

Out of Scope / Follow-ups

Item	Status	Next step
Wiring into the real dev server (handleExecuteAction, threading a real LoadModule, /__dd/executeActionViaCloud split, real preview-async calls)	Not started	Milestone 2, stacked on this PR (#481)
Real auth token / closure-scoping for real $.Actions execution	Blocked	Same as #479 — needs the single-action execution endpoint (Action Platform team)
Runtime network/subprocess guard: block net.Socket.prototype.connect, fetch, and child_process's spawn/exec/execSync for the duration of a local execution, exempted only around the internal $.Actions → executeAction call	Done	Shipped in #484, stacked on this PR

Documentation

• RFC: Confluence page 7012712651
• Kickoff doc: Confluence page 7025394455 — Milestone 1

[datadog-datadog-us1-prod]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 8292a6a | Docs | Datadog PR Page | Give us feedback!}