feat(executor): thread the defining node into ExecRequest (Phase 4b C2)

Carry the resolved script's owner (its defining node) from dispatch into
the executor so `import` resolution can be lexical (§5.5). The executing
app (`app_id`) stays the SDK isolation boundary; `script_owner` is a
separate axis — the lexical origin for imports.

- `ExecRequest.script_owner: Option<ScriptOwner>` (serde default; `None`
  falls back to `App(app_id)` in the engine for old payloads / cluster wire).
- `ScriptOwner` gains `Serialize`/`Deserialize` for the wire.
- The engine computes `default_origin` and hands it to the resolver
  (used fully in C3; the resolve() lookup already uses it).
- Every dispatch site sets it from the resolved `Script.owner()`:
  the 4 dispatcher arms (queue/trigger/http/invoke_async, via a new
  `ResolvedTrigger.script_owner`), the orchestrator id-bypass, and the
  `invoke()` SDK path (new `ResolvedScript.owner`, so a group script
  invoked by an app resolves imports from the group).

Behaviour-preserving: app scripts still resolve `App(app_id)`; group
scripts can't yet carry imports (lifted in C4).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

crates/manager-core/src/invoke_service.rs

@@ -95,6 +95,7 @@ impl InvokeServiceImpl {
         Ok(ResolvedScript {
             script_id: script.id,
             app_id: cx.app_id,
+            owner: script.owner(),
             source: script.source,
             updated_at: script.updated_at,
             name: script.name,
@@ -124,6 +125,9 @@ impl InvokeServiceImpl {
             // The execution-context app is always the caller's app — a group
             // script runs under the inheriting app, never its owner.
             app_id: cx.app_id,
+            // …but its `import`s resolve from its *defining node* (the group
+            // for an inherited script) — the lexical origin (§5.5).
+            owner: script.owner(),
             source: script.source,
             updated_at: script.updated_at,
             name: script.name,