SEP-1671: De-emphasize execution events in the task log console

[nachodd]

What changed

The task log console's primary tab strip now renders exactly two tabs, stdout and stderr. Execution events move to a low-emphasis text button beside the strip, so the panel is still one click away but no longer competes with the streams the console was opened for.

• Removed the execution-events Tab, the unreadEvents state, the prevEventCountRef counter, their resets, and the effect that set the badge. For a running task the events arrive over SSE (fetchEventSource), so the badge fired on every pushed event rather than on a fixed interval, which made it noisier than the ticket's "polling" description suggests.
• Added a subordinate Button ("Execution events") next to the tab strip. It is text-labelled rather than icon-only so events stay discoverable.
• topTab keeps 'events' as a value, so the shared activeStep, stepsForTabs swapping to eventStepOrder, the panel render, and the download guard all keep working with no edit.
• Tabs receives value={false} while the events view is open: the strip shows no active tab and MUI logs no out-of-range warning.

Acceptance criteria covered

1. Exactly two primary tabs, stdout and stderr.
2. Events reachable in a single interaction from a control subordinate to the tabs (no menu).
3. No unread indicator of any kind for events, while running or otherwise.
4. stdout / stderr keep their unread dot badges and the clear-on-select behaviour; per-step dots untouched.
5. With events open the panel keeps its search box and per-step grouping; the step strip lists the execution-event steps and selecting one filters.
6. Returning to stdout or stderr is one click; the strip shows no active tab and logs no MUI warning.
7. The download control stays disabled while events is open.
8. Events data path untouched: useExecutionEvents is called with the same arguments, SSE for running and REST for finished behave as before, and both empty states still render.
9. Existing coverage passes with the events tab-click case updated, plus new cases per AC 3, 2 and 5.

Review feedback folded in

• Keyboard reachability. MUI gives every tab tabIndex -1 when Tabs has no selected value, so value={false} would have stranded keyboard users outside the strip. stdout now keeps an explicit tabIndex 0 entry point while the strip is unselected; arrow keys move from there. Covered by a test.
• aria-current instead of aria-pressed. The control is not a toggle: a second click is a no-op and the way back is a primary tab, so it marks the current view rather than a pressed state.
• Single owner for a top-view change. The button routes through handleTopTab rather than calling setTopTab directly.

Out of scope

No backend change: the execution-events endpoints, the SSE stream, and the payload shape are untouched. useExecutionEvents and ExecutionEventsPanel are unchanged — only how the panel is reached. Demoting the UI does not defer or lazy-start the event stream.

Noted but not changed: the taskHistoryId reset effect does not reset topTab, so an open events view survives a task switch. That behaviour is identical on main and is outside this ticket.

Test plan

• pnpm --filter @sep/framework test — 750 passed across 61 files.
• pnpm --filter @sep/framework type-check — clean.
• oxlint / oxfmt --check — clean (one pre-existing warning in ExecutionEventsPanel.tsx, untouched here).

New cases: exactly two primary tabs; one-interaction access to the panel and a stable second click; no visible badge anywhere while a running task pushes events (then opening the panel proves the events did arrive); unselected strip with no MUI warning, a keyboard-focusable tab, and a one-click return; search and per-step grouping from the demoted entry point.

Merge note

main is the base. SEP-1670 (#1314) edits the line-cap select inside the second toolbar Stack, which this branch does not touch, but it is built on the three-tab structure and the removed unreadEvents state, so whichever lands second needs a rebase.

TopTab is internal and not exported, so no consumer of @sep/framework needs an edit.

Code was reviewed before opening this PR and the feedback is folded into the second commit.

[Copilot]

Pull request overview

Updates TaskLogViewer’s log console UI so the primary navigation focuses on the log streams (stdout/stderr) while keeping execution events accessible via a lower-emphasis control, aligning with the framework’s task log viewer UX direction.

Changes:

• Removes the execution-events Tab (and its unread/badge state) and replaces it with a subordinate text Button (“Execution events”) beside the stdout/stderr tab strip.
• Keeps the existing 'events' view/state plumbing (step swapping, panel render, download-disable guard), but renders the primary Tabs as unselected (value={false}) while events are open to avoid MUI out-of-range warnings.
• Updates and expands component tests to cover the new entry point, absence of unread indicators for events, keyboard reachability while the strip is unselected, and per-step behavior in the events view.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
frontend/packages/framework/src/components/TaskLogViewer/TaskLogViewer.tsx	Demotes execution events from a primary tab to a subordinate button; removes unread-event badge state; ensures MUI Tabs remain warning-free and keyboard reachable when events view is active.
frontend/packages/framework/src/components/TaskLogViewer/tests/TaskLogViewer.test.tsx	Adjusts and adds tests for the new control, verifies no events unread badge, validates unselected primary tabs behavior (no MUI warning + keyboard entry point), and confirms events step grouping/search remain functional.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.