fix: cast env-var strings before comparing in updateConfigValue

[Devin-Holland]

Summary

Fix updateConfigValue's "skip if no changes" check (config/configUtils.js:516) to cast env-var strings to typed values before comparing. Without this, every Harper restart rewrites the config file (and creates a backup) for any deployment that uses a boolean or array env var.

Why

Env vars arrive in process.env as strings — there is no boolean/number env var at the OS level. The check was using loose equality:

if (parsedArgs[arg] != flatConfigObj[arg.toLowerCase()]) {

Loose equality coerces string↔number cleanly ('9925' == 9925 → true) but not string↔boolean ('true' != true because 'true' becomes NaN, true becomes 1, and NaN != 1) and not string↔array. Any deployment with a boolean or array config env var trips the check on every boot.

This affects the default Harper Dockerfile, which sets LOGGING_STDSTREAMS=true. Every Harper container is rewriting its config and creating a backup on every restart, even with no actual config change. Same md5sum across N backups — observed in the field.

This was also the trigger for the partial-config corruption fixed in #493: every restart was opening the truncate window for fs.writeFileSync while concurrent readers were starting up. With #493's atomic write, the corruption no longer occurs, but the spurious writes and backups still happen. This PR stops them.

What changed

• config/configUtils.js:511-526: cast parsedArgs[arg] through castConfigValue (the same coercion already used by the write path 80 lines below) and deep-compare with _.isEqual.
• unitTests/config/configUtils.test.js: added two tests — one verifying string env values matching typed config values are detected as equal (the fix), one verifying genuine differences still trigger an update (no regression).

Areas to look at

• The cast covers all the cases loose-equal handled, plus the ones it didn't. Walked through edge cases ('' vs null, '0' vs null, '3d' vs '3d', null vs undefined) and didn't find a regression — the new comparison agrees with castConfigValue, which is what the actual write path uses anyway.
• castConfigValue ignores its param argument (pre-existing — there's a TS6133 diagnostic on it). Passing arg works because it's never read; if someone later wires param up, this comparison call site would need to use the canonical CONFIG_PARAM_MAP[arg.toLowerCase()] instead.
• Out of scope, intentionally. Did NOT touch the duplicate initialize() calls (launch() runs it before forking, daemon child likely runs it again). With this fix, the second call sees no diff and skips cleanly. If duplicate writes still occur after this lands, that's a separate bug.

Test plan

• npm run test:unit:config passes locally (130 passing)
• Manually verify a Harper deploy with the stock Dockerfile no longer creates a new backup on every restart

[claude]

Reviewed; no blockers found.