ci(release): speed up multi-platform image builds

[TNT-Likely]

Background

Multi-platform releases rebuild the frontend under ARM64 QEMU and do not reuse the previous release tag's GitHub Actions cache. The 0.17.4 image build and push took 12m44s with no cached BuildKit steps; its ARM64 frontend build took 323.4s compared with 56.4s on AMD64.

An existing assistant completion test can also read its shared in-memory SQLite connection while the worker is still writing the terminal event, causing intermittent release-test failures.

Root-only Python ignore patterns also allow test-generated bytecode and package metadata into the build context, invalidating the Python dependency cache between otherwise identical releases.

Changes

• Build browser assets on $BUILDPLATFORM, allowing both target images to share the native frontend build.
• Import and export the intermediate build cache through the fixed Docker Hub :buildcache tag with mode=max.
• Declare VERSION immediately before writing the version file so changing the version does not invalidate system dependency installation.
• Recursively exclude Python bytecode, pytest caches, generated package metadata and build directories, and local .docs artifacts from the build context.
• Wait for the assistant worker to finish before asserting its persisted completion events, preserving all existing assertions and avoiding concurrent reads of the shared test connection.

Validation

• pnpm --dir frontend check:ui — passed.
• .venv/bin/python with PyYAML — parsed all five workflow files successfully.
• git diff --check — passed.
• .venv/bin/python -m pytest tests/test_assistant_task_runner.py tests/test_assistant_task_events.py -q — 21 passed.
• Repeated the previously intermittent assistant completion test in 20 separate pytest invocations — 20/20 passed.
• AMD64 and ARM64 image builds and runtime smoke checks — passed on the final head (d5c88c1), including package imports, Chinese/English PDF export, production screenshots, HTTP startup, and frontend serving.
• Cache initialization build and changed-version warm build — both passed using the actual release workflow with linux/amd64,linux/arm64 and push_latest=false. Each completed python -m pytest tests/ -x -q with 1013 passed / 3 skipped and python -m pytest packages/marketdata/tests -q with 188 passed.
• The warm build took 23 seconds for build/push, with 24 direct cache hits and no pip installation or frontend compilation. Both architectures reused identical system and Python dependency layers despite the changed VERSION.
• Read the published test image layers: both architectures contained the expected VERSION, identical sets of 69 static files, and no generated Python cache entries in the application source layer.
• Confirmed the production latest manifest still matches the published 0.17.4 image. Local QA artifacts are excluded from this PR.

Measurement	0.17.4 baseline	Final warm build
Image build and push	12m44s	23s
Job including tests and setup	15m24s	2m59s

The final warm build changed only the version input; unchanged dependencies and source allowed cache reuse. The test dispatch skips release-note publication and notifications.

Boundaries and risks

Python dependency installation and runtime images continue to use the target architecture because their native dependencies must match that architecture. Cold builds or changed dependencies/local packages still require installation. These are observed warm-cache measurements rather than guaranteed timings for every release. Test image tags are separate from production versions.

Follow-up

Evaluate native ARM release runners if dependency changes still make cold ARM64 builds a significant bottleneck after these cache improvements.