fix(breadcrumb): give the icon-only home link an accessible name

[rene-schakmann]

Defect Fix

Fixes #1403

Problem

Breadcrumb always renders an icon for the home item (either home.icon or the built-in SVG), but homeAriaLabel had no default. [attr.aria-label]="homeAriaLabel" therefore resolved to undefined and the attribute was never rendered.

With the default icon-only pattern (home = { icon: 'pi pi-home' }, as used by the Basic demo) the link ends up with no accessible name:

• axe reports a link-name violation (WCAG 2.4.4 / 4.1.2)
• screen readers announce only "link"
• the accessibility tree shows link ""

Solution

The home link now falls back to a new aria.home translation key ("Home" by default) instead of hardcoded English, so the label is localizable through the locale configuration, consistent with how the other components resolve their aria labels.

Precedence:

1. homeAriaLabel when provided — unchanged behaviour
2. otherwise the aria.home translation, but only when home.label is not set

The second condition matters: when the home item has a visible label, that label already names the link, and adding an aria-label would override it (WCAG 2.5.3 Label in Name). So the fallback only kicks in for the icon-only case that actually lacks a name.

Changes

• packages/optimus-ui/src/api/translation.ts — add home?: string to the Aria interface
• packages/optimus-ui/src/config/optimus.ts — default aria.home to 'Home'
• packages/optimus-ui/src/breadcrumb/breadcrumb.ts — resolve the home link's aria-label through a homeLinkAriaLabel getter (both the href and the routerLink anchor)
• packages/optimus-ui/src/breadcrumb/breadcrumb.spec.ts — tests for the default translation, a configured translation, homeAriaLabel precedence, and the visible-label case
• apps/docs/doc/breadcrumb/accessibility-doc.ts — document how the home link is named
• apps/docs/doc/configuration/locale/apidoc.ts — document the aria.home key

Verification

ng test optimus-ui --include='**/breadcrumb/*.spec.ts' → 89/89 passing (4 new).
Prettier and lint clean on the touched files.

The generated API docs (apps/docs/doc/apidoc/index.json, apps/docs/public/llms/**, apps/docs/api-generator/typedoc.json) are left untouched since they are produced by build:docs:content.

Breaking Changes

None. Consumers that already set homeAriaLabel or home.label are unaffected; only the previously unnamed icon-only link gains a name.

---

🤖 Generated with Claude Code

[dmorfav]

@rene-schakmann, I checked this in an isolated working environment: I extracted the branch, compiled optimus-ui, and ran ng test optimus-ui --include='**/breadcrumb/*.spec.ts' in ChromeHeadless. The result was 89/89 tests passed, including the 4 new cases. The modified files were cleaner.

The precedence in homeLinkAriaLabel (homeAriaLabel → omit when home.label is visible → translate to aria.home) seems correct and respects the WCAG 2.5.3 naming convention. There's also no overlap with PR #1402: that one affects menuitem links, while this one affects home links, so the merge order doesn't matter.

It seems fine to me.

cc @geromegrignon, FYI since this follows up on the #57 thread.