Package through a pinned Node, not whatever the host has

Found the real cause of "-5: ipk verify failed": ares-package's own
packaging code (ar-async/fstream/tar, last touched 2017-2019) silently
zeroes every file's mtime in the ipk when run under a sufficiently new
Node (reproduced on v25.8.1; a Node-18 container was unaffected).
Confirmed by unpacking data.tar.gz from our built ipk (every entry
1970-01-01) versus webosbrew/hyperhdr-webos-loader's real published
ipk, structurally identical to ours (web app + native service, same
control file, same ares-cli) but with genuine October 2025 timestamps.
The archive still parses fine everywhere generic tooling looks —
Python's tarfile, our own ar/tar inspection — so nothing here ever
errors. The TV's own installer is what eventually rejects it, and it
gives no hint why.

This took three rounds of elimination to isolate: root elevation
wasn't it (Homebrew Channel's own root status was "ok"), and
system-wide native-code verification wasn't it either (a real
native-service app installed fine on the same TV). Comparing our ipk
against that known-good one byte-for-byte was what surfaced the
timestamp anomaly, and rebuilding under Node 18 reproduced correct
timestamps immediately.

build.sh now runs ares-package inside a pinned node:18 container by
default, falling back to the host's Node with a warning if Docker
isn't available. Rebuilt the actual release ipk this way and
regenerated manifest.json/repo.json against its corrected hash.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/development.md

@@ -27,8 +27,20 @@ Everywhere else, build the native part in a container:
 That bakes the SDK into an image, so it downloads once and later builds start
 immediately. There are aarch64 and x86_64 SDK builds and the image picks
 whichever matches the container, so on Apple Silicon it runs natively rather
-than under emulation. Only the compile happens in the container; packaging and
-deployment run on the host, where the TV is reachable.
+than under emulation. Only the compile happens in the container; deployment
+runs on the host, where the TV is reachable.
+
+Packaging (`ares-package`) also runs in a container by default — pinned to
+Node 18, not whatever Node the host has. This isn't optional hygiene: on a
+newer Node (v22+, confirmed on v25) `ares-package`'s own dependencies
+(`fstream`/`tar`, last touched around 2017-2019) silently zero out every
+timestamp in the ipk instead of erroring. The archive still parses fine
+everywhere generic tools look, so nothing here fails — the TV's installer is
+what eventually rejects it, as an opaque `-5: ipk verify failed` with no
+indication why. If Docker isn't available, `build.sh` falls back to the host's
+own Node with a warning; if installs fail mysteriously in that mode, this is
+the first thing to suspect — checked by unpacking `data.tar.gz` from the ipk
+and confirming the timestamps aren't 1970-01-01.
 
 Register the TV with ares once, using the Homebrew Channel's ssh (port 9922,
 root):