fix(export): give the miner exports real temperature columns

[arif-dewi]

Asana

Problem

Both miner exports emitted the whole temperature_c object into a single temperatureC field.
That is fine in JSON, but serializers.js's objectToString flattens exactly one level, so the
CSV cell rendered as:

{ambient: 36.1, max: 78, avg: 61.2, chips: [object Object], pcb: [object Object]}

Unusable in a spreadsheet — and its embedded commas break naive parsers (they broke the first
version of my own test helper, which is how I noticed).

More immediately: the M63S measures a liquid loop temperature separately from its ambient
sensor, and until now neither export could carry it. Adding a key inside temperature_c would be
legible in JSON but effectively invisible in CSV.

What this does

Adds explicit scalar columns — temperatureAmbientC, temperatureLiquidInletC,
temperatureMaxC, temperatureAvgC — via a shared mapTemperatureColumns() /
TEMPERATURE_COLUMNS pair in mappers.js, so minerStats and containerMinerStats cannot drift
apart (ops diff the two).

Appended to the end of COLUMNS, and temperatureC is left in place. Consumers read this CSV
both by header name and by column position, so inserting mid-list would break the positional
readers and removing the old column would break the by-name ones. Appending breaks neither. The
blob column can be deprecated separately, announced.

A miner that reports no liquid loop yields undefined, so JSON omits the key and CSV leaves the
cell empty rather than claiming zero degrees. (Note the mdk-prv v3 adapter coerces this to 0 —
deliberately not copied.)

No projection change was needed: FIELDS in both exports already pulls
last.snap.stats.temperature_c wholesale.

Heads-up: the data does not exist yet

temperatureLiquidInletC will be empty until a miner worker starts publishing the value.
Verified twice that it is absent today:

• live /auth/containers/group-8/miners → temperature_c = { ambient, max, avg, chips[], pcb[] }
• production export, 1322 M63S miners (18 Aug) → identical key set

This repo only re-projects the ork document, so nothing here can conjure it. Merging now means the
column is in place and populates on its own once the worker lands.

Open question for whoever owns the miner workers: production miners are type
miner-wm-m63spp, and that type does not exist in moria-wrk-miner-whatsminer — not on any
branch, not in any commit, local or tetherto upstream. Upstream ships only
m30sp / m30spp / m53s / m56s / m63, and the thing type is code-derived
(thing → miner → -wm → -m63), so that repo cannot produce -m63spp. That worker is where the
liquid read has to land.

Frontend half: tetherto/moria-app-ui#2906

Verification

• brittle tests/unit/handlers/export.handlers.test.js → 18/18 pass, 84/84 asserts
• standard clean on all touched files
• Full brittle tests/unit/** → 1475/1477. The two failures (admin_external role reads the users
  list) fail identically on a clean tree — verified via git stash — and are unrelated.

Four new tests: the liquid value lands in the right positional CSV cell (guards against
append-order drift), JSON carries it both flat and nested, an air-cooled miner omits it in JSON and
blanks it in CSV rather than reporting 0, and the two exports end with an identical temperature
block.

One fixture change worth flagging: makeMiner() carried a scalar temperature_c: 65, so none of
the nested-object handling was ever exercised. It is now the real snap shape, which is why the
pinned CSV header/row assertions move.