Refine read-path helper to augment status_details with inferred fields

Author: pinodeca

docs/exec-id-plan.md

@@ -58,19 +58,33 @@ dependency in the read path.
   1. **Drop the duroxide dependency** — read solely from `df.nodes` (one
      `SELECT` of the instance's rows). Remove `list_executions` / the fabricated
      `execution_id` cross join.
-  2. For each node, **override** the returned `status` (and `status_details`) to
-     the *effective* value at read time, derived from ancestors:
-     - **Leaf→root climb:** find the first ancestor whose `execution_id` is not a
-       prefix of the node's. Ancestor `failed` ⇒ `skipped`; `running`/newer
-       execution ⇒ `pending`; `completed` but branch/iteration not taken ⇒
-       `skipped`; RACE loser ⇒ `cancelled`.
-     - Use the IF decision and RACE winner recorded in `status_details`
-       (Step 6) to know which branch/iteration is "taken".
-  3. Children are reachable via `left_node`/`right_node`; the tree is immutable
+  2. For each node, **leave `status` and the stored `execution_id` untouched**
+     and instead **add inferred fields to the returned `status_details`**:
+     - `inferred_status` — the *effective* state at read time (`skipped`,
+       `cancelled`, `pending`, or the node's own physical status when no
+       ancestor overrides it).
+     - `inferred_status_from_ancestor_id` — the node whose state *determined*
+       `inferred_status` (the first ancestor whose `execution_id` is not a
+       prefix of this node's). Makes the derivation explainable per row.
+     - We deliberately do NOT add `inferred_status_execution_id`: it is just the
+       `execution_id` of `inferred_status_from_ancestor_id`'s row, so a reader
+       can join to that node if needed.
+     - Rationale: the read path **must not compete with the write path**. By
+       augmenting (not overwriting) `status_details`, the helper never races the
+       orchestration's fenced writes. (If we later materialize this at the DB
+       level it would compete — defer that decision.)
+  3. **Derivation (leaf→root climb):** find the first ancestor whose
+     `execution_id` is not a prefix of the node's; that ancestor's state sets
+     `inferred_status`. Ancestor `failed` ⇒ `skipped`; `running`/newer execution
+     ⇒ `pending`; `completed` but branch/iteration not taken ⇒ `skipped`; RACE
+     loser ⇒ `cancelled`. Use the IF decision and RACE winner recorded in
+     `status_details` (Step 6) to know which branch/iteration is "taken".
+  4. Children are reachable via `left_node`/`right_node`; the tree is immutable
      after `df.start()`, so no parent column is required (optional safe
      denormalization only).
-- Output columns: surface `status_details` alongside `status`; the implicit
-  states appear only here, never in the base table.
+- Output columns: `status` and `status_details` keep their stored values; the
+  inferred fields live inside the returned `status_details` JSONB only, never in
+  the base table.
 
 ## Step 4 — Document the `execution_id`
 
@@ -88,7 +102,9 @@ dependency in the read path.
   execution) drawn dashed, with a clear note that the dashed ones exist only in
   `df.instance_nodes` output.
 - Document the inference helper used by `instance_nodes` (the ancestor-climb /
-  derivation function): inputs, the prefix rule, and each case.
+  derivation function): inputs, the prefix rule, each case, and that it emits
+  `inferred_status` + `inferred_status_from_ancestor_id` into `status_details`
+  rather than mutating the stored `status`/`execution_id`.
 
 ## Step 6 — RACE winner recording (small behavioral add)