fix(startos): audit packaging — drop stale sdk-build, add aarch64, complete i18n

[helix-nine]

Full audit of the StartOS packaging ahead of Community Registry listing. This fork maintains only the StartOS wrapper: it consumes the image upstream publishes and never builds or pushes one of its own. Changes are confined to startos/, the build files, and CI — no application code is touched, so the fork stays cleanly rebasable on upstream.

What was broken

sdk-build/ shipped stale duplicate source. Its build script copied startos/*.ts in before bundling, but 19 of those copies were also committed, frozen at version 0.1.1:0 and image tag 0.5.2 while startos/ said 0.5.3. Deleted; the package now builds startos/ directly.

CI was publishing container images from this fork. Both release.yml and test-build.yml built the app and pushed it to ghcr.io/<this repo>. This fork maintains only the StartOS wrapper, so both jobs are gone: each workflow now just packs an s9pk against the tag named in the manifest, and nothing in CI writes to a container registry.

That also removes a destructive bug. test-build.yml rebuilt the released tag as amd64-only on every push to main and force-pushed it over the multi-arch image, plus :latest — which is why 0.5.2 in GHCR has no arm64 layer while 0.5.3 still does.

The manifest locked out ARM. arch: ['x86_64'], although the published 0.5.3 image is genuinely amd64 + arm64 — which excluded every ARM server. Now ['x86_64', 'aarch64'], verified by packing the aarch64 s9pk.

A dead duplicate setInterfaces in index.ts. start-core reads only main/init/uninit/createBackup/manifest/actions from the bundle, so it was never invoked. Restored to canonical plumbing.

Four version files with no-op migrations. v0_4_2/v0_4_7/v0_5_0/v0_5_2 all had empty up. Removed, other: []. The packed manifest still reports canMigrateFrom: "<=0.5.3:1", so every prior install upgrades in one hop.

The alerts block no longer exists in SDK 2.0. It passed typecheck only because setupManifest infers its generic from the argument, and was discarded at pack time regardless. Removed.

The marketplace long description was factually wrong — it advertised "BraiinsOS+ / CGMiner API", predating the asic-rs rewrite.

i18n was a scaffold, not an implementation. translations.ts was an empty stub. Now es_ES/de_DE/pl_PL/fr_FR across all six keys, plus those locales on the manifest descriptions and release notes.

startos/README.md was a dead scaffold citing a manifest.yaml that does not exist and StartOS 0.4.0.x. Rewritten against the packaging guide's writing-readmes.md; instructions.md rewritten against writing-instructions.md.

Also: SDK 2.0.6 → 2.0.9, main.ts defers to the image CMD via sdk.useEntrypoint() instead of duplicating it, packageRepo points at this fork, and stale release steps corrected in CONTRIBUTING.md and CLAUDE.md.

Known limitation, now documented

The service writes nothing to its mounted volume. All user state — miner list, names, captured power ceilings, and saved miner API passwords — lives in the browser's localStorage (blisspoint.state.v2). So main mounts at /data and stays empty, and Backups.ofVolumes('main') captures nothing: a restore yields an empty miner list. Confirmed empirically on the box. Changing it is an application decision, so this PR documents it prominently in both the README limitations and the user-facing instructions rather than leaving the backup silently implying it works.

Test plan

Verified on a real StartOS 0.4.0.1 box (x86_64):

1. make x86 → builds and packs blisspoint_x86_64.s9pk at v0.5.3:1, sdk 2.0.9. make arm also packs, confirming the arm64 image resolves.
2. start-cli package install -s blisspoint_x86_64.s9pk → installs as 0.5.3:1.
3. start-cli package start blisspoint → daemon starts; logs show Blisspoint serving on :80.
4. Health check goes green: {"result": "success", "message": "The web interface is ready"}.
5. Inside the container: node server/serve.cjs on 0.0.0.0:80 and proxy-rs on 127.0.0.1:8081 only.
6. LAN egress works — the container reached a host and the gateway on the local /24. This is the whole premise of the service.
7. GET /api/scan?subnet=<lan> swept a real /24 and returned cleanly.
8. Web UI reachable over the LAN through the StartOS gateway; SPA fallback and /api/health both work end-to-end.
9. stop is immediate and clean (no PID-1 signal hang, so runAsInit is not needed); start returns to green.
10. /data confirmed empty after install, start, restart and a scan.

Not covered: miner control itself — pause/resume and power-target were not exercised against real hardware, as no ASIC was available on the test network. The transport around them is verified; the control paths are not.