[v2] Flyte UI actions stop loading on large runs

### Describe the bug

I have noticed that when running a large flyte.map with 10000+ actions, the UI only loads a total of 5999 and then stops. Everything has run successfully, this appears to be a UI bug only.

### Environment

- flyte-binary v2 chart v2.0.42
- flyteconsole-v2 image ghcr.io/unionai-oss/flyteconsole-v2@sha256:3cea5ec7ea1ebb2d2b392d60988c028ff45965e3a7eecb0e1ba51d7ec81e6cdb
- flyte Python SDK 2.6.1
- Running on EKS

### Steps to reproduce

- Execute a run that fans out to >6,000 actions and let it reach a terminal phase. You can use a cached task so it doesn't actually have to schedule them all.
- Open the run detail page in the UI after it is complete.

### Claude diagnosis

This is what claude has said is the root cause:

src/hooks/useRunDetailState.ts subscribes to RunService.watchActions and, in parallel, runs a 5-second heartbeat that tears the stream down as soon as the root action is terminal:

```
const heartbeat = setInterval(() => {
const isTerminal = isActionTerminal(useRunStore.getState()?.run?.action)
// stop polling if we've reached terminal state
if (isTerminal) {
controller.abort()
...
```

For a completed run, a0 arrives with its terminal phase in the first stream message, so the very first heartbeat tick aborts the stream — regardless of how many child actions have arrived. The terminal check is being used as a proxy for "the stream has nothing more to send", which it isn't.

What survives is therefore "however many actions the browser could ingest in ~5 seconds". The backend sends actions in batches of 1,000 (plus the root repeated in each batch), and the client consumes whole messages, so the visible count lands on a multiple of 1,000 minus the root row: 6 batches → 5,999 rows.

WatchActions re-emits the entire action set every ~60 seconds for a run that has already reached a terminal phase, indefinitely — 28,599 action messages over two minutes for this 10,286-action run. The console's premature abort currently hides this, so fixing the abort above without addressing the resend will leave the page rebuilding the full tree every minute.