Added transient storage for nodes

[JPPhoto]

Summary

Feature: Add transient_storage to InvocationContext as per-workflow ephemeral state. A single transient_storage dict is created at the start of a workflow execution and passed into each node's freshly built InvocationContext, enabling nodes to share small amounts of in-process data during one graph run. The storage is reset between workflow executions; nodes that rely on transient_storage should therefore set use_cache=False in their @invocation decorator to avoid cached outputs bypassing required read/write side effects.

Related Issues / Discussions

QA Instructions

1. Run the unit tests:
   • pytest tests/test_graph_execution_state.py
2. Verify the new transient storage tests pass:
   • Confirms transient_storage is available and isolated per workflow execution.
   • Confirms values written in one execution are readable by downstream nodes in the same execution.
   • Confirms values do not leak into a subsequent graph execution (fresh context).
3. (If adding/adjusting any nodes that use transient storage) Ensure those nodes are declared with use_cache=False in the @invocation decorator and verify their behavior does not change when invocation caching is enabled elsewhere.

Merge Plan

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• ❗Changes to a redux slice have a corresponding migration
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[JPPhoto]

Why is this useful? When we have branching or proper for loops, or the ability for a node to re-execute each iteration (another PR in the works), state suddenly becomes really useful and/or important. This is the framework for making some of those changes down the road.

[JPPhoto]

Note: I tried adding the transient storage to the invocation cache but the issues are that 1) execution order isn't guaranteed, and therefore 2) we'd have to include the transient storage prior to invocation when creating the cache key. I can make these changes and add a test if that's the decided route or we can make it part of the node contract that nodes using transient storage cannot use the cache. Thoughts?

[dunkeroni]

I'm not a big fan of intentionally breaking encapsulation, determinism, and order dependence in a way that users can't see or predict. Is there no possibility to support this using plugable dictionary inputs instead?

[JPPhoto]

I'm not a big fan of intentionally breaking encapsulation, determinism, and order dependence in a way that users can't see or predict. Is there no possibility to support this using plugable dictionary inputs instead?

I'm not sure what you mean here - inputs into what?

We already make no guarantees about determinism; the goal here is to have a framework for the future when we add control flow.

I have a WIP branch that removes the requirement of use_cache=False, making these changes completely transparent to nodes. Would that approach work? I can merge with this after I get the kinks worked out.