Fix native Linux build and add a native Linux CI job

[koppor]

🤖 This description was generated by Claude Code.

Stacked on #5812 (linux-wine-ci) — it needs that PR's shared lib-def fixes. GitHub will retarget this to master automatically when the base PR merges and its branch is deleted.

What

cmd/build-linux.ts (native Linux build of all dependency libs plus the portable test_util / test_engines tools) had drifted from premake and from recent source changes:

• test_util sources synced with premake: DocProperties.cpp, PdfDarkModeImageRules/Oklab.cpp and their _ut tests — all called unconditionally by test_util.cpp and SumatraUnitTests.cpp, so the link was broken
• test_engines: add the a-gumbo dependency lib (GumboHtmlParser needs it) and the PdfCadDetect / PdfCadEnhanceDevice / PdfDarkModeNoOp sources premake lists for it
• stale archive names in the link list (libzlib.a / libopenjpeg.a → liba-zlib.a / liba-openjpeg.a)
• link -lcrypto: Crypto_posix.cpp uses OpenSSL's MD5 (the native build now needs libssl-dev)
• wrap the test_engines archives in -Wl,--start-group: harfbuzz is built with custom allocators (sumatra_hb_*) whose definitions live in mupdf's mupdf_load_system_font.c, behind harfbuzz in link order — single-pass ld can't resolve that without a group

ext/a-openjpeg/opj_malloc.h: include the x86 intrinsic headers before the #pragma GCC poison malloc …. clang — unlike gcc — enforces poison inside system headers, and mm_malloc.h (pulled in by the SSE headers that a later chunk of the amalgamation includes) calls malloc. Never seen on macOS because arm64 has no xmmintrin.h. (Note: regenerating the amalgamation via cmd/a-openjpeg.ts would drop this line; its own validateCompile step will catch that.)

CI: extends .github/workflows/linux.yml with a native job (same debian:trixie container): builds all dependency libs with clang, runs test_util's unit-test suite natively on Linux as part of the build, and links test_engines.

How tested

On Linux, inside a debian:trixie container (same as the CI job):

bun cmd/build-linux.ts -debug
# -> all dependency libs build
# -> out/linux-dbg64/test_util links and its unit-test suite passes (run by the build)
# -> out/linux-dbg64/test_engines links

The workflow job was validated locally with nektos/act in the same container. No Windows-facing changes in this PR (build-linux.ts is Linux-only; the opj_malloc.h change is inside #if defined(__GNUC__)).

🤖 Generated with Claude Code

[koppor]

I don't know why this diff is so short when reading #5631 (comment)

[koppor]

Rendering works - but UI would need to rewritten - we first "wait" for the macOS port - and then work on Linux (I guess)

[kjk]

@koppor I don't really have a preference about doing mac or linux first.

It's just I use mac and not linux, so it's easier for me to work on mac.

If you want to work on Linux UI feel free. You can commit directly, no need to wait for me to review - it's a lot of work and wouldn't be efficient to wait for approval for every change.

Just don't break Windows build.

I think I started on the right foundation for mac/linux port.

My general idea is to replicate the Windows UI but no need to be 100%. Especially in the beginning it's more important to implement features that reproduce windows UI 100%.

I prefer re-using as much code/logic from windows but I understand the realities. It's ok to duplicate, sharing code can always be improved in the future.