fix(processlist): show Windows priority classes as labels in the NI column (#3672) - #3673

Closes #3672.

What was wrong

On Windows psutil reports the Win32 priority class in nice, not a nice value. The class values are neither ordered nor small — 32 is normal while 32768 is above normal — so the NI column showed a five-digit number that means nothing as a nice value and overflows a column formatted {:>3}.

What this does

Renders the six classes as the short labels Windows itself uses, in the TUI and the WebUI alike, exactly as the issue specifies:

I checked those six values against psutil on the machine rather than copying them, and the test asserts the map against the constants themselves when it runs on Windows — so a psutil change fails the test instead of quietly rendering a raw number again.

Three things it deliberately does not change:

• The API. nice stays the raw value, so sorting, exports and any consumer of /api/*/processlist are untouched. Only the two display layers translate.
• The alert. get_nice_alert() still receives the number. The nice_* limits in glances.conf are POSIX nice values, so matching a label against them would silence them — there is a test pinning that.
• Unknown classes. An unmapped value falls through to its number rather than disappearing, so a class Windows adds later stays visible.

ProgramlistPlugin inherits _get_process_curses_nice, so the program view is covered by the same change.

Verification

Windows 11, Python 3.14, psutil 7.2.2.

tests/test_core.py     47 passed, 6 skipped
ruff check / format    clean on both changed Python files

The new test_010b_processes_nice_windows_labels patches WINDOWS both ways, so both branches run on every OS rather than only on a Windows runner.

Mutation-checked, after confirming each edit actually applied:

display_nice never maps          -> 1 failed
map applied on every platform    -> 1 failed   (the POSIX assertions catch it)
alert given the label            -> 1 failed

The third one exists because the "alert keeps the raw value" claim above is a comment, and a comment nothing tests is just a hope.

About the rebuilt bundle

public/glances.js is regenerated, since every .vue commit in the history ships it.

Worth flagging how it was produced, because my first attempt was wrong. Building on a Windows checkout injected CRLF into the HTML-comment string literals webpack inlines, which changed the bundle in places unrelated to this fix. I set core.autocrlf=false, re-checked out the tree, and confirmed that an unmodified build then reproduces the committed public/glances.js byte for byte before rebuilding with the change. So the bundle delta here is only this change, and browser.js is untouched.

WebUI

eslint on the changed component reports 0 net new issues — 5 errors / 75 warnings before and after, all pre-existing in that file.