feat(dl-item-tooltip): match in-game tooltip styling

[victorblino]

Updates dl-item-tooltip to more closely match the in-game tooltip layout and visual behavior.

Changes include:

• Reworked tooltip layout, spacing, typography, stat blocks, section ordering, and component item footer styling.
• Preserved section order from API data instead of reshuffling innate/ability content.
• Added inline description icon/text coloring using API class names such as Spirit, SpiritDamage, BulletResist, MeleeDamage, Heal, MoveSpeed, Slow, and related variants.

Before:

After:

Validation:

npm -w @deadlock-api/ui-core run build

[victorblino]

maybe some specific items aren't displaying correctly some colors, but we can fix them if we notice

[raimannma]

for me this looks way more different to the game, at least the background is missing

[victorblino]

fixed backgrond and another few things

in-game (just for reference)

[zenojunior]

Hey @victorblino! The visual result looks great, especially the alignment with the in-game tooltip. Before approving, I'd like to request a few targeted adjustments. Nothing that changes the end result, just to reduce the diff size and keep consistency with the rest of the project.

1. Class naming convention

The rest of the project uses kebab-case throughout (.mod-box, .tier-badge, .ability-type-label, etc). This PR introduces PascalCase classes (InlineAttributeName, InlineKey) alongside the kebab versions, which doubles the selectors.

Suggestion: normalize the API classes inside formatDescriptionHtml:

html
  .replace(/class="InlineAttributeName ([^"]+)"/g, 'class="inline-attribute-label $1"')
  .replace(/class="InlineKey"/g, 'class="inline-key"')

Then drop all .InlineAttributeName.* / .InlineKey selectors from the CSS. Should cut a fair number of lines.

2. Duplicated CSS variables

There are two schemes living side by side: --courageBrightColor + --tooltip-courage-bright, --offWhite + --tooltip-off-white, etc. I'd keep only --tooltip-* (clear component scope) and remove the others.

3. Category variants

The inline coloring rules list every variation (.Heals, .Healing, .Heal, .Regen, .MaxHealth). Worth double-checking: does the API actually return all of these? If so, we could map them to a semantic category in the TSX:

const ATTR_CATEGORY = { Heals: 'heal', Healing: 'heal', Regen: 'heal', /* ... */ };

And the CSS becomes one rule per category via data-kind. If some variants don't appear in practice, even better, drop them and keep only what's real.

4. formatDescriptionHtml safety

Could you add a quick test ensuring raw HTML input (<script>, <img onerror>) is escaped before the binding replacement runs? Just closing the XSS door, since the description comes from the API.

The rest looks great. The breakdown into renderBlockProperty, renderTimingPill, and renderComponentGroup is clean, and unifying cooldown / charge-up into findSectionTimings makes sense.