fix: toolbar overflow button aria-label and decorative icon svgs

[marinaionel]

Fixes #804.

The overflow-tabs button's labelKey pointed at tabs.overflowMenu, a translation key that was never actually defined anywhere in the locale catalog. The i18n plugin falls back to returning the raw key string when a translation is missing, so this button ended up with a garbage/non-meaningful accessible name instead of a real one. Switched it to menu.moreOptions, the same label the analogous left-action-menu:overflow-menu button already uses for its "..." dots icon.

Every generated toolbar icon component (and the custom-icon renderer in icon.tsx) always rendered its <svg> with role="img" and aria-label={title}, but no caller ever passes a title, so every icon inside an already-labeled button ended up as an <svg role="img"> with no accessible name at all, which axe-core flags directly. Now role/aria-hidden are conditional on title: no title means the icon is marked decorative (aria-hidden, no role="img"), matching the icon's actual purpose inside a labeled button. If a caller ever does pass a title, the icon still gets role="img" + aria-label as a standalone labeled image.

Left the responsive-breakpoint behavior mentioned in the issue (#585) alone since this is only about the accessible-name/decorative-icon gap.

[vercel]

@marinaionel is attempting to deploy a commit to the CloudPDF Team on Vercel.

A member of the Team first needs to authorize it.