Add details about unsupported Sync item states

[nightnei]

Proposed Changes

On Sync tab we render “Upgrade plan” button, w/o any details about which one should be chosen.
It can be frustrating for users, if they click in “Upgrade plan” button, purchase for example “Personal” and still Studio asks to upgrade plan, w/o any details.
This PR adds tooltip to specify Business plan.
And also adds tooltip to explain why the site is unsupported. It even usefull for us, developers of Studio, since I had no idea why site can be unsupported and why that predicate can be true, so I had to read commits history.

Testing Instructions

1. Open sync tab
2. Find any Unsupported item and Upgrade plan button
3. Assert that you see tooltips

[wpmobilebot]

📊 Performance Test Results

Comparing 09287a6 vs trunk

site-editor

Metric	trunk	09287a6	Diff	Change
load	4335.00 ms	7054.00 ms	+2719.00 ms	🔴 62.7%

site-startup

Metric	trunk	09287a6	Diff	Change
siteCreation	9054.00 ms	9079.00 ms	+25.00 ms	🔴 0.3%
siteStartup	3959.00 ms	3952.00 ms	-7.00 ms	🟢 -0.2%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change

[gavande1]

I have tested this and noticed something unusual. It would be great if you could address it. There's a brief moment when the tooltip appears in the top left corner before moving back to its intended position. I captured a video and took a screenshot to demonstrate exactly what happens. You can see the tooltip appear at the 12-second mark, then move to its proper place.

CleanShot.2026-01-07.at.18.38.39.mp4

[gavande1]

I left a comment about the issue with flashing tooltip on top left corner.

[nightnei]

@gavande1 Interesting, I can't reproduce it. But I added placement="bottom" to help lib decide where to render it, maybe it will fix the issue. If it doesn't fix, then I will take a look a bit more, but then it means that it's internal library issue and we should eitehr replace lib or live with it, since I don't think that debugging/fixing lib would be good approach, especially with such not critical thing.
Test it please one more time.

[gavande1]

@nightnei Unfortunately that didn't fix the issue as it seems.

CleanShot.2026-01-08.at.13.28.01-converted.mp4

but then it means that it's internal library issue and we should eitehr replace lib or live with it, since I don't think that debugging/fixing lib would be good approach

I totally agree. Would it make sense to identify the root cause and report the issue upstream repo in that case?

[nightnei]

@gavande1 I created issue (STU-1201) for it and set low priority, since it's not a blocker and it doesn't cause any UX problems. Also, the lib is used across the whole Studio, so it should be reproducible for you everywhere, and the changes in this PR are not the root cause for it.
So I propose to merge this PR and handle that issue later separatelly.

[katinthehatsite]

I see the same issue with the flashing tooltip although it does not happen with every tooltip, but for some sites it does.

[gavande1]

Thanks for addressing this and creating STU-1201 for the tooltip issue!

After further review, I agree this PR should be merged:

1. ✅ The code changes add valuable UX improvements
2. ✅ The tooltip flashing is a pre-existing @wordpress/components library issue, not introduced by this PR
3. ✅ STU-1201 properly tracks the tooltip issue for separate resolution

Approving this PR. The tooltip library issue can be investigated and fixed separately without blocking these helpful improvements.

[ivan-ottinger]

Thank you for introducing these tooltips, Vova!

[gavande1]

@nightnei This PR uses Tooltip from @wordpress/components, but Studio uses a custom Tooltip from src/components/tooltip everywhere else. Switching to the custom component should fix the flashing and maintain consistency.