Add structured hover detail cards for compressed or non-obvious website items

[hummat]

Problem

The website now exposes a lot of dense analytical data, but many important labels are still compressed, abbreviated, or domain-specific.

Examples:

• score abbreviations and dimension names on the build list (Ovr, Prk, Cur, BP, Scl)
• weapon cells that compress melee/ranged details into a tight table cell
• perk, blessing, and curio chips that show only the display name
• synergy edges, anti-synergies, and isolated picks that assume the reader already understands the model
• breakpoint action rows and unsupported/missing calculator states that do not explain enough inline
• compare-page diff chips and coverage/family labels that are clear only if you already know the scoring vocabulary

The current site is usable if you already understand the project, but it is still too opaque for readers who are not already fluent in the scoring/synergy/calculator model.

Goal

Add a single, consistent hover-detail system for items that are not fully self-explanatory, so the site can stay dense without being cryptic.

This is not “put tooltips on everything.” It should only cover elements where the visible label is compressed, ambiguous, or hides important context.

Recommended design

Use one reusable website-wide hover-card primitive instead of ad-hoc title attributes.

Interaction model

• desktop: hover + focus opens a styled detail card
• keyboard: focusable triggers with the same content as hover
• mobile/touch: tap-to-open fallback (popover/sheet pattern, not hover-only)
• cards should be dismissible and should not trap pointer movement in a frustrating way

Content model

Every hover card should use the same small structured shape:

• title
• subtitle optional
• summary (one sentence)
• facts (flat key/value rows)
• sourceLabel optional (scorecard, structure, calculator, synergy model, etc.)

This content should come from typed adapters/helpers, not hand-written strings scattered through route files.

Scope

In scope

Add hover detail where it clearly improves comprehension:

• build list score headers / abbreviations
• build list weapon cell
• build detail slot labels where the visible text is too compressed
• talent, perk, blessing, and curio chips
• synergy edges, anti-synergies, isolated picks
• coverage labels / family labels / concentration-type metrics
• breakpoint action labels
• missing / unsupported breakpoint states
• compare-page score deltas, slot diffs, structural diff chips, synergy/breakpoint diff items

Out of scope

Do not add hover cards to basic obvious controls:

• back links
• plain nav links
• compare button
• tab buttons
• simple form labels unless they hide behavior the user cannot infer from the visible UI

Content expectations by item type

Score dimensions

Explain:

• full dimension name
• what it measures
• score range / max
• how to interpret high vs low values

Weapons

Explain:

• slot
• full weapon name
• family when useful
• compressed multi-weapon cells should split melee/ranged cleanly

Perks / blessings / curios

Explain:

• full label
• tier / value / rating when available
• whether validation came from scorecard or structure
• avoid leaking raw internal IDs by default

Synergy items

Explain:

• edge type
• strength
• families involved
• existing explanation text from the model
• for anti-synergies / orphans: why the item is flagged

Breakpoints

Explain:

• action label in human terms
• scenario / difficulty context when relevant
• missing vs unsupported should be clearly distinguished
• unsupported cards should say what class of calculator support is absent, not just “no data"

Architecture constraints

• one shared hover primitive, not repeated route-specific tooltip markup
• one shared content adapter layer for analytical/domain objects
• no raw title-attribute sprawl except maybe as a temporary fallback during migration
• preserve accessibility: keyboard focus, sensible semantics, non-hover fallback
• keep cards concise; if a card needs paragraphs, the underlying page copy is wrong

Rollout order

1. Introduce the shared hover-card primitive and content model.
2. Apply it to the build list first (highest density / biggest readability gain).
3. Apply it to build detail page domain items.
4. Apply it to compare page diff surfaces.
5. Remove any temporary native title usage that duplicates the new system.

Acceptance criteria

• A single reusable hover-detail pattern exists and is used consistently across the website.
• Compressed or ambiguous analytical items have hover detail; obvious controls do not.
• The build list, detail page, and compare page all use the shared system.
• Keyboard users can access the same detail content.
• Touch/mobile users have a non-hover fallback.
• No user-facing hover card exposes raw internal IDs unless a future explicit debug mode is added.

[hummat]

Blocked by #27 (design system foundation) and #26 (IA restructure). Hover cards are a polish layer for a visual language and component structure that don't exist yet. Building hover detail on top of the current uniform card treatment means the hover content has no visual home.

[hummat]

Sequencing update: #27 is done locally on main but not pushed yet. After that lands on GitHub, the remaining dependency for this issue is #26 only. Local roadmap has already been updated to reflect #26 -> #25.