Feature: Build Euro-Office for arm64 Windows/Linux

[rikled]

This PR adds fixes and a github workflow to build Euro-Office on arm64 Windows and Linux.

depends on: #37, Euro-Office/desktop-apps#31, Euro-Office/core#114

[rikled]

@chrip, if you're planning to work on reviewing the Wayland PR, could you review this one first? Then we can test Wayland directly on arm64 and x64 linux.

[chrip]

Review draft — #39 "Build Euro-Office for arm64 Windows/Linux"

Adds arm64 build support: a Windows arm64 cross-compile job for v8/openssl, arm64 matrix legs for the Windows and Linux builds, PRODUCT=desktop wiring into core-base, and submodule bumps (core → the arm64 core#114 head, desktop-apps). Depends on core#114, DesktopEditors#37, desktop-apps#31.

Build check (what I ran)

I cloned the PR and built the core-base target with PRODUCT=desktop for linux/arm64 — the exact config build/linux/docker-bake.hcl uses. Result: success (exit 0). Notably this refutes a concern raised against the dependency PR (core#114): the http://apt.llvm.org/jammy/ llvm-toolchain-jammy-13 repo does publish arm64 packages, and clang-13/lld-13/libc++-13 install cleanly on the noble 24.04 desktop base. The heavier stages (desktop-common JS, 3rd-party v8/cef/boost/qt compile, the editor itself) are CI-oriented and impractical to build on this box, so I validated the base image + config coherence rather than the full pipeline.

Findings

1. [Medium] crosscompile-3rdparty-arm64: implicit handoff, over-broad gating, exploratory comments.

• The arm64 v8/openssl outputs are conveyed only via the Nextcloud remote cache (ensure_dep upload → download in build-windows), not an explicit artifact. If NEXTCLOUD_USER/PASS are unset (fork PRs get no secrets), the upload silently no-ops and the arm64 Windows build won't find the cross-built deps.
• build-windows has needs: [build-common, crosscompile-3rdparty-arm64] with no per-matrix guard, so the amd64 Windows leg also waits on — and is skipped by a failure of — the arm64-only cross-compile job.
• The job ships an ASSUMPTION: block and a "see notes in chat" reference. Per AGENTS.md ("excessive comments/dead code must be removed"), clean these before merge.

2. [Medium] Windows Win10 SDK + VC v141 toolset + ATL/MFC install is commented out (both build.yml and build.ps1), replaced only by aqtinstall. DesktopEditors historically requires the v141 toolset + ATL/MFC; if the windows-11-arm/windows-2022 runners don't already provide them (v141 ARM64 ATL/MFC is not default), the build fails to link. Confirm they're preinstalled or genuinely no longer needed.

3. [Low/Altitude] desktop-common is plumbed three inconsistent ways, one of which looks stale: CI uses type=tar → extracted dir context ./common; the root bake uses type=oci → oci-layout://../deploy/common:${TAG}; build.ps1 uses type=docker; build.sh uses target:desktop-common. Every real path overrides the oci-layout:// context, so that default appears unused. Consolidate or document the intended flow.

4. [Trivial] Missing trailing newline at EOF of .github/workflows/build.yml and build/docker-bake.hcl.

Positives

• PRODUCT=desktop cleanly wired into core-base — verified to build on arm64/noble.
• aqtinstall added in CI and build.ps1 InstallDeps — this resolves core#114's qt/aqt finding for this pipeline.
• Import-VcVars correctly maps arm64 → vcvarsarm64.bat.

Verified NOT issues

• VERSION → VERSION.txt rename is complete (only build.sh reads the file; workflow/build.ps1 use PRODUCT_VERSION).
• desktop-common.tar dest (./common.tar under bake workdir: ./build) matches the upload path ./build/common.tar.
• The jammy-clang-13-on-noble concern — disproven by the successful core-base build.

Assisted-by: ClaudeCode:claude-opus-4-8