fix(#3735): fix tooltip position in Work Side Menu and add to toggle button

[bdfranck]

This PR adds the following fixes to the Work Side Menu:

• Adds tooltips to the Toggle button and the Search button in Docs for better usability.
• Ensures consistent tooltip alignment, both horizontally and vertically, even when the menu is offset.
• Adds a component token to allow dynamic setting of the menu height.

[bdfranck]

I forgot to remove this from a previous PR. It was causing errors so I removed it here.

[twjeffery]

Looks great to me

[vanessatran-ddi]

We should rename this handleToggleHover() instead of showToggleTooltip() as it may cause the confusion between showTooltip and showToggleTooltip.

Also we can shorten like this:

function handleToggleHover() {
if (open) return;

setTooltipPos("Expand menu", _toggleButtonEl);
showTooltip();
}

so under button below we can do like this:

<button ...
on:mouseenter={handleToggleHover}
on:mouseleave={hideTooltip}
on:focus={handleToggleHover}
on:blur={hideTooltip}

[vanessatran-ddi]

Do you have the token PR for this new variable? I don't see it on 2.2.2:

[vanessatran-ddi]

Question: was the reason for using a custom <button> here (instead of wrapping WorkSideMenuItem with a sentinel URL like /search) specifically to display the ⌘K keyboard shortcut as trailing content?

I asked because the doc site already has an established pattern for non-navigation items using WorkSideMenuItem + URL + wrapper onClick
For example: ComponentsSubMenu

If the ⌘K is the only blocker, we could drop it and use the badge like now instead, then we can add a story to follow up for trailingSlot on the WorkSideMenuItem.

If we can use WorkSideMenuItem instead of button here then we can have tooltip feature without having to add a customized function here.

cc @twjeffery How do you think?