[Feature] Tagger performer match improvements

[Stash-KennyG]

Enhance Tagger performer match UX with hover previews and mismatch warnings

Provides a performer hover-pop-over to the tagger UI so performers can be clearly seen and verified against potential match candidates before committing stashID changes in the local database.

Closes #6853

Improves match confidence at the decision point, reducing accidental performer cross-linking when multiple people have similar names.

For existing users, this should improve speed and tagging accuracy because identity verification happens inline instead of requiring extra page navigation.

In larger libraries, this should reduce correction/rework effort (unlinking and relinking performers) and improve long-term data quality.

Additional operational benefits:

• lower cognitive load during tagging (less context switching);
• faster moderation/review workflows for users curating shared libraries;
• fewer follow-up data repairs caused by incorrect performer associations.

Scope and Non-Goals

• Scope is intentionally limited to the Tagger workflow (Scene Tagger performer match context).
• This does not attempt to redesign global performer hover behavior across all pages.
• This is a UX assist for matching decisions, not an automatic identity resolution system.

Platform and Interaction Considerations

• Current interaction model is hover-based, which is optimized for desktop pointer devices.
• On mobile/touch interfaces, hover interactions are naturally limited or unavailable.
• This is acceptable for initial delivery given the Tagger workflow is primarily desktop-driven, but should be disclosed for product discussion.

Functionality Details

• Adds a hover preview for matched performer selection in Scene Tagger by attaching the preview to the picker control, when a match is suggested by name

• Adds a stashbox performer hover preview on the left performer label using scraped/remote data, while rendering through shared performer card UI for visual consistency.

• Adds mismatch context in the matched performer hover card for non-matching performer fields (including aliases/URLs as counts), to make potential cross-linkage easier to spot before save.

• Adds stash ID conflict warning inside the hover card when the local selected performer already has a stash ID for the same endpoint but with a different GUID. Uses a compact red endpoint chip for stash ID conflict warning, with full conflicting GUID available via chip tooltip.

Behavior Details

• Picker hover target: hover card opens from the selected picker control.
• Left-side scraped hover: hover on scraped performer text shows card built from scraped data (image/name/etc.) but styled with shared PerformerCard.
• Mismatch rows: shown only for fields where scraped has a value and differs from selected local value.
• Aliases / URLs: reported as counts only.
• Stash ID conflict warning:
  • shown only when attached stash_id != incoming remote_site_id AND attached stash_endpoint == incoming stash_endpoint
  • displayed inside card, above mismatch rows
  • compact red endpoint chip; GUID is tooltip text.

Mismatch Fields Covers

• Birthdate
• Death Date
• Ethnicity
• Hair Color
• Eye Color
• Height
• Weight
• Penis Length
• Circumcised
• Measurements
• Fake Tits
• Tattoos
• Piercings
• Career Start
• Career End
• Aliases (count)
• URLs (count)

Test Plan

• [✅] Hover selected performer picker in Scene Tagger matched result and confirm card opens below picker.
• [✅] Hover left scraped performer name and confirm scraped preview card appears and matches shared performer card styling.
• [✅] Confirm mismatch rows render only for differing values and are hidden for exact matches.
• [✅] Confirm aliases/URLs mismatch rows show only in Remote > Local.
• [✅] Confirm stash ID warning appears only when endpoint matches and GUID differs.
• [✅] Confirm warning chip is compact red endpoint chip and GUID is visible in tooltip.
• [✅] Confirm no stash ID warning appears when GUIDs match.
• [✅] Check regressions
  • Performer card on scene details unaffected
  • Performer popover on scene card unaffected
  • Tagger workflow unaffected on scenes and performer view
• [✅] Confirm lint/build checks pass.

Notes

• This feature is designed to improve confidence in match correctness before save, especially in larger datasets where name collisions are more common.

LLM Details

[✔] LLM use is openly disclosed. Made with Cursor
[✔] Code is reviewed by a human.
[✔] Human testing and validation was performed.
[✔] You take full responsibility for the code (including license compliance).

[Gykes]

Static review only, no actual testing was done.

[Gykes]

Another static review.

Looking better, once these are addressed/chatted about I will do app testing.

[Stash-KennyG]

What Changed Since PR Opened

• Refactored hover rendering so PerformerPopover is now the shared hover controller for this feature path.
• Added previewData support to PerformerPopover to safely render scraped performer previews without unsafe casting.
• Added PerformerPreviewCard in components/Performers as a shared typed preview renderer.
• Moved shared preview-popover styling ownership to components/Performers/styles.scss (.performer-preview-popover) and removed Tagger-owned shared styling.
• Preserved full PerformerCard behavior for ID-based popovers (favorite icon, counters/chips, overlays) by restoring PerformerCard in PerformerPopover local-ID mode.
• Kept Tagger-specific extras (stash ID conflict chip + mismatch rows) as appended card content inside matched popovers.

Data Shape Strategy (No Unsafe Casts)

• PerformerDataFragment and ScrapedPerformer are intentionally handled through separate adapters.
• Scraped/remote preview uses typed previewData mapping.
• Local/matched preview uses id mode in PerformerPopover plus lazy details fetch for mismatch/warning logic.
• No as unknown as style casting is used to coerce incompatible performer types.

Hover/Lazy-Load Behavior

• Matched performer detail query is hover-scoped:
  • Opens on hover (onOpen)
  • Stops querying on close (onClose)
• Prevents eager fetching for large scrape result pages while preserving content.

UI/Styling Adjustments

• Consolidated duplicate preview card CSS.
• Updated border color to theme token ($secondary) for consistency with dark theme styling.

CI/Validation Fixes Applied

• Fixed stylelint property ordering in Tagger/styles.scss.
• Applied Prettier formatting fixes for updated files.
• Confirmed latest PR checks pass after these adjustments.

[Gykes]

So, after some quick testing of the feature it looks okay. There is a small UX thing that I noticed and not sure if it is intended.

1. Search for a scene that has greater than 1 performer
2. Hover the first performer
3. The new modal is considered part of the hover and does not go away if you are hovering the name or the new modal
4. To hover the next performer you need to move outside of the box and it feels a little clunky.

From a UX standpoint I would image that, since there is no hyperlinked information in this modal, then it should go away when you remove your hover from the name of the performer on the tagger card. This is, of course, opinionated and I think no matter what way you do it you will get pushback.

In my opinion, the hover should disappear when you move your mouse off of the performer name. With that in mind lets go ahead and go that route and if there is a large enough of a pushback then we can revert.

[Stash-KennyG]

Current behavior is intentional. When you hover a performer and the modal appears, it remains active if the cursor moves into the modal. That allows click or ctrl/middle-click actions directly from the modal (open stash or stashdb).

The primary driver was the right side where that interaction did not exist before. The left side already supported it, but I kept behavior consistent across both sides rather than introducing different hover models.

Implementation differs slightly (inline block vs box picker), but both treat the modal as part of the hover region by design.

Net effect: dismissal is lateral movement, not vertical.

The suggestion is valid from a simplicity standpoint. Current design prioritizes interaction over quick dismissal. If that tradeoff proves wrong, it can be adjusted, but would lose the ability to interact with the card in case someone wanted to get more details. Also, in highlighting performer mis-matches - interaction with middle click may be necssary...

[Gykes]

If it is intentional then you can keep it as is. I imagine that people will want to be directed to the Stash Box link to verify performer at some point. Off the top of my head I don't have a solution for the issue I was having but I don't think it's a massive one. I think this is mostly ready for WP review anyway so will probably give it another quick look over and test then send it his way,