fix: sd-tooltip staying invisible when reopened during its hide animation

[SchulteDev]

Description:

Reopening sd-tooltip while its hide animation was still running (~150 ms) left it open but
invisible: open === true, but body.hidden === true and popup.active === false.
Reachable by clicking the trigger three times quickly, or tabbing onto it, away and back.

• A show/hide that is superseded by a newer one now stops instead of finishing its work.
• stopAnimations() targets the element that is actually animated (popup.popup).
• A superseded show/hide no longer emits sd-after-show / sd-after-hide, so these events
  always match the final state. show() / hide() still resolve, once the latest
  transition has ended.

Not part of this PR: sd-dropdown, sd-dialog and sd-drawer show the same defect.

Definition of Reviewable:

• E2E tests (features, a11y, bug fixes) are created/updated
• relevant tickets are linked

[changeset-bot]

🦋 Changeset detected

Latest commit: 5d7a9aa

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@solid-design-system/components	Patch
@solid-design-system/mcp	Patch
@solid-design-system/styles	Patch
@solid-design-system/tokens	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mariohamann]

Hey @SchulteDev,

thanks for taking the effort of creating this PR. We discussed this in our team and involved our design team here as well. While we see, that this implementation would be technically more "correct", we barely see a real-life risk. While we understand, that the current behaviour could irritate users, we believe this is a very edgy edge case. In addition we believe, that users (unfortunately) are used to use weird behaviour when things are clicked very very fast.

One of our main principles is to stay maintainable as much as possible, and we currently see too much additional complexity in comparison to real life usage. As you mentioned, this would have to be adapted for the other components as well, leading to additional code there as well.

Hoping for your understanding, that we're therefore closing this PR.

Nevertheless, we're happy about your contribution and encourage you to continue with that! To avoid potential disappointment, it would be helpful to create a (short!) issue upfront, so that we can discuss it in the team first.

[SchulteDev]

@mariohamann
Thanks for the feedback; of course, that decision is up to the team.
The “very edgy edge case” part is certainly true for end users. However, this bug was discovered during browser testing; Playwright runs so fast that the current behavior requires avoidable “waits” in the tests. Therefore, I’d like to ask that you also take this use case into account when evaluating this improvement—in my opinion, the PR is reasonable.