[enumeratio]

Zeta(s) at a complex s takes the Hurwitz kernel at a = 1, so its digits are vouched for or the call stays unevaluated. Fixes #552

• library/arithmetic.ts, Zeta handler: a finite complex literal s under N() (or a float operand) calls hurwitzZetaComplexWithError(s, 1), the kernel HurwitzZeta(s, 1) already uses. A declined kernel (undefined or a NaN value) leaves the call as it is. A real s keeps zeta/bigZeta. zetaComplex and riemannZetaComplex are unchanged: the polylog Crandall expansion reads them.
• The result is a double at every precision, as for the other complex special functions.

Accuracy, against mpmath 1.3.0 (decimal operands), 64 points, Re s from -5.5 to 3 (including 0, 1 and 0.1), |Im s| from 1 to 10⁶:

	answered	worst relative error
before	64	1.6e-9 (at Im s = 10⁶); 7.3e-11 at 10⁵; 5.9e-13 at 400 and 1000; 26 points above 1e-13
after	48	9.1e-14

The 16 points with |Im s| >= 10⁵ are declined, as HurwitzZeta(s, 1) already declines them: those calls, which used to print a value with 9 to 13 correct digits, are now unevaluated. A call takes about 2 ms at Im s = 400.

Tests: test/compute-engine/zeta-complex-vouched.test.ts has the 48 answered rows at precisions 15, 21 and 30, each also checked to equal HurwitzZeta(s, 1) exactly, the 16 declined rows, exact operands symbolic under evaluate(), a float operand under evaluate(), and the pole and real arguments unchanged.

Left alone: Zeta is a real-only lowering in compiled code (JS_REAL_ONLY_LOWERINGS), so a complex operand is NaN there, by that design. The Hurwitz kernel's own double-double pass is what vouches here; I did not widen its bound.

Merge: git merge-tree of this branch with #535 and #536 conflicts only in CHANGELOG.md (each adds the ## [Unreleased] heading); arithmetic.ts merges cleanly.