chore: bump pozeiden v0.3.0 → v0.4.1, zigmark v0.11.0 → v0.11.1

[tsunaminoai]

Bumps pozeiden from v0.3.0 → v0.4.1 and zigmark from v0.11.0 → v0.11.1, and fixes the tooling issues the bump surfaced (update-zon lock truncation, noisy zig build test / update-golden output).

What PolicyPress picks up

• O(V+E) flowchart layout — graph caps raised 10× to 10 000 nodes / 20 000 edges; a 1000-node graph went from 1.39 s to ~12 ms
• Rendering fixes: YAML front matter no longer leaks into diagrams as nodes; >64-layer / >128-wide flowchart layouts are no longer silently corrupted; 0.4.1 fixes direction-override subgraphs swapping same-layer node positions
• Default font stack now ends in Liberation Sans, DejaVu Sans, sans-serif — Typst resolves real fonts out of the box (PolicyPress's per-call Source Sans 3 override still applies and still wins; it could be revisited later)
• Accessibility metadata: mermaid accTitle:/accDescr: directives become SVG <title>/<desc> + role="img"; pozeiden 0.4.x also adds renderWithMetadata returning the title/description as strings — the upstream follow-up the comments in src/diagrams.zig/src/typst.zig name for replacing the hardcoded aria-label="Diagram" (left for a separate PR)
• Hardening: per-call max_input_bytes, mindmap depth + subgraph-count guards, XML-safe output
• zigmark 0.11.1 bumps its lazy pozeiden pin v0.2.0 → v0.4.1. That stale 0.2.0 entry sat in this repo's lock alongside the direct dependency and predated both 0.3.0 GHSA fixes (SVG/XSS injection, out-of-bounds writes); the lock now carries a single pozeiden entry at v0.4.1.

Fix: update-zon could truncate the zon lock

zig2nix's zon2lock truncates its destination before it starts fetching, and it stages its zig fetch runs in a /tmp scratch dir — so the dev shell's project-relative ZIG_GLOBAL_CACHE_DIR=.zig-cache made it write each repacked dependency tarball under /tmp/zig2nix_*/.zig-cache while reading it back from <repo>/.zig-cache. Every dependency bump crashed with FileNotFound (zon2lock.zig:462) and left a truncated build.zig.zon2json-lock behind.

Fixed here rather than as a follow-up:

• the dev shell exports an absolute cache path ($repo/.zig-cache), so the write and read sides agree no matter where a tool chdirs;
• update-zon cds to the repo root, re-anchors the cache itself (robust against stale shells), generates into a temp file, jq-validates the result, and only then moves it into place (pozeiden's guard) — a crash can no longer eat the lock.

Verified: a fresh update-zon run completes cleanly and reproduces the committed lock byte-identically (idempotent across the 0.4.1/0.11.1 bump too).

Fix: zig build test / update-golden looked like build-runner failures

Neither actually fails — both exit 0 — but every run ended in a misleading failed command: … dump. Root cause: the zig 0.16 build runner re-prints any stderr captured from a passing step, under a failure-styled block (the success paths never clear step.result_failed_command). Two stderr sources fed it:

• the test suite deliberately drives warning paths; the 18 tests that intend to warn now bracket themselves with std.testing.log_level = .err (err-level logs stay fatal — the test runner counts them before the filter), and praxis_join's diagnostics move from std.debug.print to a scoped std.log (identical message text; now respects --quiet and no longer corrupts --json-log) so they're silenceable the same way;
• golden_gen is a Debug executable, where std.log defaults to .debug, so tomlz's .parser-scoped internals leaked on every real baseline regeneration; it now sets std_options with a .warn threshold (baselines go to stdout either way).

A clean zig build test / zig build update-golden now prints nothing and exits 0.

Verification

• zig build test: 111/111 passed, zero stderr, exit 0 (the earlier "build-runner wrapper failure" was the cosmetic dump above — diagnosed and gone)
• zig build update-golden: all Typst baselines byte-identical under v0.4.1/v0.11.1 — pozeiden's changelog flags SVG byte changes, but PP's goldens don't re-pin mermaid SVG (src/golden.zig: "golden-tested upstream"), and the 0.4.1 layout fix doesn't touch the committed fixtures — so no regen needed
• update-zon: regenerates the lock byte-identically; guard rejects invalid/empty output and keeps the existing lock
• nix build .# — fetches the new pins by lock hash and builds clean end-to-end
• nix fmt — no changes

Companion PR: sc2in/zigmark#86 (merged, released as v0.11.1) bumped zigmark's lazy pozeiden pin.

[github-actions]

Preview deployment

Preview environment deleted on PR close.