feat(trace): plumb parentRunId from cloud_run and replay entry points

[alectimison-maker]

Summary

• _startTraceRun now forwards parentRunId / parentSessionId from runOptions into trace.startRun, giving derived runs a way to name their origin.
• The two fork points produce real lineage data:
  • the cloud run controller passes the active browser run on the tab (and its conversation id) as parent;
  • replaySavedWorkflow links the current run and its conversation.
• Root runs keep null/0 exactly as before; a missing parent falls back to null with no new failure path.

Motivation

Closes #2871.

The lineage fields from the recorder-side PR (parentRunId/parentSessionId/delegationDepth) had no producers: without call sites passing parent info, the fields would stay empty for every run and the attribution capability would be dead weight. Cloud runs (cloud-runs.js) and workflow replays (replaySavedWorkflow) are the two entry points with clear fork semantics, so they are the first to propagate parent run info.

Design

• _startTraceRun reads runOptions.parentRunId / runOptions.parentSessionId (optional-chained, || null) and passes them into trace.startRun. Call sites that don't provide them are unchanged — the recorder stores null/0 as before.
• Cloud run dispatch (chrome cloud-runs.js) threads agent.currentRunId?.get?.(tabId) and agent.conversationIds?.get?.(tabId) as parent — i.e. a cloud run launched while a browser trace run is active on that tab is recorded as that run's child. Cloud runs launched standalone (e.g. from the scheduler) record as roots.
• replaySavedWorkflow passes the tab's active currentRunId and conversation id the same way.
• Propagation carries only run/session ids — no message content — preserving the privacy contract.
• Firefox has no cloud-runs module (platform boundary: cloud runs depend on Chrome-side infrastructure), so the cloud plumbing is Chrome-only; the agent.js plumbing is mirrored to both builds.

Testing

• node test/run.js — passed, 1955 tests (3 new):
  • functional: cloud run controller threads parent lineage from the active browser run (mocked controller, asserts the exact runOptions handed to agent.processMessage);
  • functional: controller tolerates an agent without lineage maps (falls back to null, no crash);
  • source-level: _startTraceRun and replay plumbing present in both builds; Firefox cloud-runs absence asserted as the platform boundary.
• node --check on every touched file — passed

Skipped: unpacked-browser manual verification (no browser session available in this environment); the cloud-run path is exercised through the existing mocked-controller harness instead.

Compatibility and risks

• No API/format changes: the plumbing only populates fields the recorder already stores (null/0 default).
• Risk: none identified beyond the recorder-side behavior already reviewed — a run that is genuinely standalone records as a root, which is the current behavior.

Scope

Deliberately deferred: scheduler entry points (no parent/child semantics today — evaluated later), planner (its events already live inside the same run, no fork).

[vercel]

@alectimison-maker is attempting to deploy a commit to the esokullu's projects Team on Vercel.

A member of the Team first needs to authorize it.