fix(deps): update dependency saxonche to v13

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
saxonche	>=12.8.0,<13.0.0 → >=13.0.0,<13.1.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[maudetes]

We have in issue with harvest previews in uwsgi context with saxonche v13 (ie try preview this harvester with saxonche v13):

graal_create_isolate error
Fatal error: Failed to enter the specified IsolateThread context. (code 2)

We don't encounter any error in the celery worker or with a python interpreter, only in the uwsgi context on dev & demo.

[ThibaudDauce]

Why this fails under uwsgi

saxonche 13 reserves 32 GiB of address space when a CSW backend creates its
PySaxonProcessor — reserved only, never used: RSS stays at 58 MiB. saxonche 12
doesn't do this at all (294 MiB VmSize). It comes from the GraalVM runtime that
13 is built on and we can't tune it: saxonche exposes no way to size the isolate.

Our uwsgi workers run with limit-as = 1024, which caps virtual memory, so the
reservation blows past it and the isolate can't be created:

graal_create_isolate error
Fatal error: Failed to enter the specified IsolateThread context. (code 2)

It's a native exit, not a Python exception — the whole worker dies, not just the
request. Celery and the REPL are fine because only uwsgi sets limit-as; this
isn't a demo vs production difference, production would fail the same way.

CI is green because no test runs under a memory limit. Added one that starts
Saxon in a subprocess under RLIMIT_AS = 1024 MiB: green on 12.10, red on 13.0.

What supporting 13 would require

Both our memory guards measure virtual memory, which stopped being a proxy for
real usage now that a dependency reserves without committing. Raising them isn't
an option either: limit-as would need ~34 GiB, at which point it protects
nothing.

; limit-as = 1024      ; drop — kills the worker over reserved-but-unused memory
; reload-on-as = 768   ; drop — would recycle the worker after every Saxon request
reload-on-rss = 192    ; keep — this is the one that tracks real memory
evil-reload-on-rss = 256   ; add — see below

reload-on-rss only recycles a worker between requests. Cutting one off
mid-request is the one thing limit-as did that we'd lose, and
evil-reload-on-rss gets most of it back: the master kills the worker as soon as
it sees RSS over the limit, without waiting for the request to finish. Not an
exact swap — the kernel enforced limit-as at allocation time, the master only
polls — but it bounds memory we actually use, which the VSZ caps no longer do.

Saxonche v12 vs v13

13 gives us nothing: XSLT/XPath 4.0 is PE/EE only, we run HE with an XSLT 1.0
stylesheet, we don't use the schema API, and the restored extension functions are
something we deliberately disable (allow-external-functions: false). 12.10.0
(2026-07-14) is newer than 13.0.0 (2026-05-29), so the 12 branch is still
maintained and staying on it costs us no fixes.

[ThibaudDauce]

Test added in #3882, so this PR should become red after merging to main and rebasing it.

[streino]

That's a pretty crazy change in memory footprint! Probably worth pushing upstream (I can do it if you'd like)?

we run HE with an XSLT 1.0 stylesheet

The SEMIC converter bumped to XSLT 2.0 on main, and an udata upgrade in under way. FYI only since it doesn't impact your conclusions.

[ThibaudDauce]

That's a pretty crazy change in memory footprint! Probably worth pushing upstream (I can do it if you'd like)?

we run HE with an XSLT 1.0 stylesheet

The SEMIC converter bumped to XSLT 2.0 on main, and an udata upgrade in under way. FYI only since it doesn't impact your conclusions.

This is not really a change in memory footprint since it's reserved memory and not used (it doesn't even need this physical memory on the computer as I understand it)

[streino]

It's not active footprint but still, it claims it might use that much, and it would make sense to be able to tune it for the very reason you're hitting.

From the GraalVM doc I see MaxHeapSize (which I'm guessing is the main culprit) is set by default to a % of total RAM (with the actual % depending on the configured GC).

I couldn't find much more than this thread https://saxonica.plan.io/boards/4/topics/9976, which claims it's not easy to do in SaxonC :/

There's absolutely no emergency as you explained, but I'm worried we might at some point bump into a security update or something similar that will only be available in version 13.