ci(docker): build the web bundle natively; fail a hung multi-arch build fast

[gangtao]

What happened

The v0.0.7 Docker run ended cancelled — not by a person and not by the concurrency rule. Its all-in-one job hung for exactly 6 h (GitHub's default job timeout; the workflow set none) after this, 50 s in:

#28 [linux/arm64 webbuild 4/6] RUN npm ci
#28 15.33 qemu: uncaught target signal 4 (Illegal instruction) - core dumped

Node crashed under arm64 QEMU emulation on the amd64 runner and buildx never returned. The tpk-app job had already finished, so timeplus/tpk-app:0.0.7 existed (and is what production runs) but timeplus/tpk:0.0.7 was never pushed. A re-run of the same commit (attempt 2) succeeded in 3 min — a one-off emulation crash, but the exposure is structural.

Change

• deploy/docker/Dockerfile: FROM --platform=$BUILDPLATFORM node:22-alpine AS webbuild. The web bundle is plain JS/CSS, identical for every target platform, so it is built once on the build host and copied into both images. Node no longer runs under emulation at all — which also removes a redundant second npm ci + npm run build from every multi-arch build.
• .github/workflows/docker-publish.yml: timeout-minutes: 30 on both jobs (normal runs take 2–4 min). A hang now fails within the hour and shows as a failure, not a cancellation six hours later.

Verified

• amd64 cross-build from an arm64 host (docker buildx build --platform linux/amd64 --target app) completes; the webbuild steps run without a platform prefix, i.e. natively on the host, instead of [linux/amd64 webbuild] under emulation.
• Both 0.0.7 images now exist on Docker Hub (from the re-run), so nothing is blocked on this PR.
• Workflow YAML validated. This PR's own CI run exercises the changed Dockerfile on the amd64 runner (PR builds are single-arch; the multi-arch path first runs on the next push to main).

🤖 Generated with Claude Code