[Diagram Editor] Circular fork operations and edit-popover positioning

[ArizmendiWan]

Fork and join operations are easier to distinguish from processing nodes when rendered as compact circles. This PR keeps Fork Clone, Fork Result, Split, Unzip, and Join as separate operations, updates their static port styling, and places edit popovers beside the selected node within the available canvas.

Progress tracing, WebSocket batching, message-flow animations, and playback are preserved in #228. This PR retains the existing runtime and interaction API.

Demo

Validation

• All 160 frontend and REST integration tests pass.
• TypeScript and Biome checks pass.
• Embedded frontend rebuilt for this scope.
• Verified that this source diff and the progress PR together preserve every source change from c5c45c2.

The two PRs target main independently. Their generated frontend archives must be rebuilt when combining them.

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.

[ArizmendiWan]

I have narrowed the scope this PR to its initial intention, as the progress visualization and the events need further consideration.