[menubar] Why not use Base UI `Toolbar` for this component?

### Describe the issue

The current `MenuBar` component appears to closely match the semantics and behavior of **Base UI’s `Toolbar` component**, rather than Base UI’s `MenuBar`.

The documented examples (e.g. bold / italic formatting actions) represent a classic toolbar use case: a horizontal group of icon buttons with toggleable active state and immediate actions.

Given that Kumo is built on top of Base UI, it’s unclear why a custom `MenuBar` abstraction is used instead of directly leveraging Base UI’s `Toolbar`.

---

### Current behavior

- Renders a horizontal row of icon buttons
- Actions are triggered immediately via `onClick`
- Supports active state (`isActive`)
- No menu hierarchy or nested menu items
- Matches formatting / editor toolbar patterns

---

### Why this is confusing

In Base UI:

- `Toolbar`
- Designed for grouped controls and icon buttons
- Ideal for formatting actions (bold, italic, etc.)
- `MenuBar`
- Represents a semantic application menu
- Contains menus and menu items
- Focused on navigation and command discovery

Kumo’s `MenuBar` behavior aligns with `Toolbar`, not `MenuBar`.

---

### Question / clarification requested

- Is there a reason Base UI’s `Toolbar` component is not used here?
- Is this an intentional abstraction or a naming choice?
- Are there behavior or styling differences that prevent using `Toolbar` directly?

Clarifying this would help consumers understand the intended semantics and accessibility expectations of the component.

---

### Environment

- Package: `@cloudflare/kumo`
- Version: `1.0.0`
- Browser: All
- OS: All

---

### References

- Kumo MenuBar docs: https://kumo-ui.com/components/menubar/
- Base UI Toolbar: https://base-ui.com/react/components/toolbar

Start with the Kumo MenuBar documentation and compare its documented behavior with Base UI's Toolbar reference. No source file, test, or concrete change is named, so first determine whether this is an intentional abstraction or a component replacement. Done requires a decided direction and clear documentation of the resulting semantics and accessibility expectations.

Written by the indexing model from the issue text.