fix(webui): colour a container's CPU and MEM the way curses already does

[ntdatt812]

The defect

The containers plugin decorates each container's CPU and MEM in update_views(), against that container's own threshold from the config file ([containers] cpu_careful=…), falling back to the global one:

alert = self.get_alert(i['cpu']['total'], header='cpu', action_key=i['name'])
if alert == 'DEFAULT':
    alert = self.get_alert(i['cpu']['total'], header='cpu')
self.views[i[self.get_key()]]['cpu']['decoration'] = alert

The curses view reads both back. plugin-containers.vue did not — it rendered the two cells as plain text, in both its narrow (d-md-none) and wide (d-none d-md-block) tables.

So a container above its limit is red in the terminal and black in the browser. It is silent from either side: get_views() answers 'DEFAULT' for a key it cannot find, so a missing binding looks exactly like a deliberately undecorated column.

The change

.vue only, plus a test. The component already exposes the views it needs — it uses them for show_engine_name and show_pod_name — so this adds a getDecoration() reader and four class bindings (two cells × two tables).

The reader is defensive the same way plugin-diskio.vue is: a container present in stats but not yet in views returns undefined rather than throwing.

The limit column next to memory usage stays undecorated on purpose: the server classifies usage against that limit, so the limit itself carries no alert.

Evidence

There is no JS test harness here, so the added test pins the server half of the pair — the half the new binding depends on. Without it, removing the decoration upstream would take the colour out of both front ends with nothing failing.

Two-way mutation, run locally:

Mutation	Result
none	3 / 3 pass; with the existing test_plugin_containers.py, 18 / 18
drop the server-side ['cpu']['decoration'] = alert	2 fail

One note on the test itself: my first version configured containers_cpu_careful=… and the alert came back DEFAULT, which looked like a second bug. It was my config — inside [containers] the key is section-relative (cpu_careful). The test now says so in a comment, since it is an easy trap for the next person writing one.