UI/UX improvements around fork operations and progress visualizations

[ArizmendiWan]

This PR redesigns fork operations and streaming feedback in the diagram editor.

Current changes include:

• combine Fork Clone, Fork Result, and Split into a single Fork operation with a behavior selector
• keep node editing popovers within the canvas without covering the selected node
• represent streaming handles as hollow amber ports and pulse when messages pass through them

Edit:

Updated the PR with following changes:

• Fork/Branch operations (including Clone, Result, Split, Unzip and Join) are now separate nodes represented by circular shape.
• Allow edge and node to visualize message activities with updated message signals

Demo

New circular nodes:

Left to right: Clone, Result, Unzip, Split, Join

New effects of message flow:

Screen.Recording.2026-08-21.at.01.53.11.mov

Screen.Recording.2026-08-22.at.13.45.01.mov

GenAI Use

We follow OSRA's policy on GenAI tools

• I used a GenAI tool in this PR.
• I did not use GenAI

Generated-by: Codex

[mxgrey]

This small visual change is a huge improvement in helping the diagram structure feel more intuitive to users.

I would just recommend two tweaks:

• Let's not combine Fork Clone, Fork Result, and Split into a single UI. Instead we continue to treat them as different operations, but render them all as the new circle shape.
• Let's also use this circle shape for unzip.

[ArizmendiWan]

• Kept Fork Clone, Fork Result, and Split as separate circular operations, and made Unzip circular.
• Replaced the blinking streaming handle with an edge glow for every message. Frequent messages keep the edge glowing; it fades once messages stop.

[mxgrey]

Based on testing it looks like c5c45c2 has fixed the issue reported in #225 🎉

[mxgrey]

@ArizmendiWan I appreciate that you've taken the initiative to come up with this operation activity tracker since I haven't been able to set aside time for it, but I think the methodology here is more brute force than I'd prefer.

I haven't fully digested all the implementation details, but it looks to me like your approach is to put guardrails on the outside of all operations broadly to try to infer their levels of activity.

If we were to go a level deeper, I believe there will be more direct ways to assess the ongoing activities of an operation. For example, ActiveTasksStorage and ScopedSessionStorage tell us information about what is happening inside of an async service or a scope respectively. I was planning on adding a new method to the Operation trait to check an operation's liveliness, and each operation implementation can check their respective components as needed. This is similar to how Reachability is implemented.

My main concern about the approach you're using here is it might not generalize well. It makes assumptions from the outside about what can or cannot happen on the inside of an operation. For example, what if we some day have an operation where a single input message internally produces numerous parallel threads of operation which are not directly observable from the outside?

I'll try to find some time this week or early next week to implement what I have in mind.