extras/pi: toolPendingBg and toolSuccessBg are the same colour in all four styles

[DresvyanskiyDenis]

Summary

lua/tokyonight/extra/pi.lua assigns the same colour to two different tool states:

"toolPendingBg": "${bg_highlight}",
"toolSuccessBg": "${bg_highlight}",

So in the generated extras/pi/tokyonight_*.json, a tool that is still running and a tool that
finished successfully render as the same panel. All four styles are affected, since they all come
from this one template.

Evidence

CIE76 ΔE between the three tool-state backgrounds, computed from the four files currently on main:

style	pending / success	pending / error
night	0.00	10.48
storm	0.00	3.57
moon	0.00	8.40
day	0.00	10.32

The pending/success column is exact identity, not near-identity.

The error column is a second, milder instance of the same thing: colors.tool_error_bg = util.blend_bg(colors.error, 0.05) is a 5% blend, which in storm lands 3.57 from the pending
background — below the ~5 ΔE where a flat colour field reads as a different colour at all. The other
three styles are fine there.

Why this survived review

It is invisible to a contrast check. Contrast is a luminance ratio, so two panels of equal lightness
score ~1.0 against each other whether they are identical or complementary — the collapsed pair passes
every WCAG-style floor cleanly. We only found it after switching a theme test from contrast to ΔE.
Worth mentioning in case other extras/ generators are reviewed the same way.

Suggested fix

The repo already defines the right colours and already ships them for this exact semantic.
lua/tokyonight/extra/delta.lua uses ${diff.add} and ${diff.delete} for added and removed lines,
which is the same success/failure grounding a tool panel wants:

"toolPendingBg": "${bg_highlight}",
"toolSuccessBg": "${diff.add}",
"toolErrorBg": "${diff.delete}",

In night that gives #243e4a and #4a272f against pending #292e42 — ΔE 11.49 / 20.70 between each
panel and pending, and 27.06 between success and error. It also drops the bespoke
util.blend_bg(colors.error, 0.05) line, so the three states come from palette entries that already
exist rather than from one derived value.

We are running that change locally against pi and it looks right in a real session, though only for
night and day — moon and storm we have not eyeballed.

Happy to open a PR if the direction suits you.