fix(quicklook): colour each --percpu bar by that core's own load - #3716

In --percpu mode the quicklook bars are per core, but their colour was not: every bar was drawn with the aggregate CPU style.

• curses: _msg_create_line reads self.get_views(key=key, option='decoration'), and key is 'cpu' for every row _msg_per_cpu emits.
• WebUI: plugin-quicklook.vue calls getDecoration('cpu') inside the v-for over percpus.

So on a box where one core is pegged at 100% and the rest are idle, that core's bar is painted with the colour of the average — the one number that cannot show it. The cpu_careful/warning/critical limits are configured and correct; nothing reads them per core.

The change

update_views now publishes views['percpu_decoration'], a style per cpu_number plus 'other' for the row that averages the cores neither interface displays (CPU* in curses, x in the WebUI). Both interfaces read that one map, so they agree by construction rather than by both getting it right separately. The WebUI falls back to the old aggregate style when the key is absent, so an older server does not break a newer page.

The styles come from the plugin's own quicklook_cpu_* limits directly rather than through get_alert(). That is deliberate: get_alert() also calls manage_threshold, which writes glances_thresholds[stat_name] that glances/events_list.py:153 reads, and manage_action, which can run a configured [quicklook] command. Both are keyed by the stat name alone, and every core shares quicklook_cpu with the aggregate — so running the cores through get_alert() would leave whichever core went last as the value the event list and any action see. _decoration_for_percent is the same threshold ladder with none of that.

One unrelated token: msg = msg = f'{key.upper():3}* ' on a line the change already touches loses its duplicated assignment.

Verification

pytest tests/test_plugin_quicklook.py is 22 passed; tests/test_core.py tests/test_glances_curses.py tests/test_lazy_views.py is 63 passed, 6 skipped. ruff check and ruff format --check are clean on both changed Python files.

Each claim was checked by breaking it, and each mutation fails only the test that owns it:

The first is the one that matters: without it the map is correct and unread, and every other test still passes.

The summary-row test picks values where the row disagrees with both of the things it could have borrowed — four cores at 95% and two at 60% give CRITICAL bars, a WARNING aggregate (83%), and a CAREFUL row.

I have no Linux box to hand for the curses rendering itself; the assertions above are on the message list msg_curse builds, not on the terminal output.