[enumeratio]

D(ErfInv(x), x), D(HurwitzZeta(s, x), x), D(Beta(a, b), a) and the other heads below evaluate to a closed form on every route instead of an inert Apply(Derivative(…)), and D(x^5, [x, 3]) is 60x². Fixes #574

Rules (symbolic/derivative.ts, SPECIAL_FUNCTION_PARTIALS, consulted just before DERIVATIVES_TABLE; each entry is one closed form per operand and undefined for an operand with none, which keeps that slot's Apply(Derivative(f, eᵢ), …) with the chain rule over the others, as the PolyLog and Gamma(s, z) arms do):

• ErfInv(x) ′ = (√π/2)·e^(ErfInv(x)²) (DLMF 7.2.1, inverse-function rule).
• HurwitzZeta(s, a) in a: −s·HurwitzZeta(s + 1, a) (DLMF 25.11.17). LerchPhi(z, s, a) in a: −s·Φ(z, s + 1, a); in z: (Φ(z, s − 1, a) − a·Φ(z, s, a))/z. None in s.
• Beta(a, b): B(a, b)(ψ(a) − ψ(a + b)) in a, and in b with ψ(b).
• LogBarnesG(z) ′ = (z − 1)ψ(z) − z + ½(1 + ln 2π); BarnesG is that times BarnesG(z).
• EllipticK(m) ′ = (E(m) − (1 − m)K(m))/(2m(1 − m)), EllipticE(m) ′ = (E(m) − K(m))/(2m), the one-operand forms only (DLMF 19.4.1).
• ClausenCl(n, θ) for a literal n ≥ 1: Cl₁′ = −½cot(θ/2), Clₙ′ = Clₙ₋₁ for an even n, −Clₙ₋₁ for an odd one. A symbolic order stays inert.

The same rules answer Derivative(f, …) and, through it, the coefficients of Series: Series(ErfInv(x), x, 0, 5) is ½√π x + π^(3/2) x³/24 + 7π^(5/2) x⁵/960 + O(x⁷) (Wolfram's series).

Left inert on purpose (no closed form, Wolfram leaves Derivative[…] too): ∂ₛ of HurwitzZeta, LerchPhi and ClausenCl, Zeta'(s). The two-operand Zeta(s, a) is not given the shift rule: it is Σ|n + a|^(−s) here, for which −s·ζ(s + 1, a) is wrong at a negative a.

D(f, [x, n]) (library/calculus.ts, isOrderSpec): the canonical handler read only a Set pair as the order spec; it now reads a List of a symbol and a number too, with every rule of the Set pair (order 0 removes the pair, a negative order is an error, a fractional or symbolic order and an order past MAX_DERIVATIVE_ORDER stay as written).

Tests: test/compute-engine/derivative-special-functions.test.ts (new): each function at points of its domain, D(…) under evaluate() and .N() against a central difference of the function, the same compiled (BarnesG has no JavaScript lowering, before or after), the chain rule (EllipticK(2x), Beta(x, x)), exact forms, the inert slots (including a closed-form slot added to an inert one), a variable-free operand, the Series of ErfInv and HurwitzZeta, and D(f, [x, n]) against {x, n} and against D(f, x, x, …) (orders 0, 3, 5, 7, a compound function, a negative, fractional, symbolic and past-the-cap order, and a list of two variables). Pinned tests changed (two): measurement-apply.test.ts listed Beta(2.5 ± 0.1, 3) among the operators "with no known derivative" that stay unevaluated; it now has one and is a Measurement, so the row moves to a test of its own. compile-references.test.ts used D(ErfInv(x), x) as the derivative that glsl cannot lower although it lowers ErfInv; it is a closed form now (glsl lowers it), and the test uses D(Zeta(x), x), which stays an Apply(Derivative(Zeta, 1), x). The rest of the D, Derivative and Series rows on main pass unchanged. Compilation: a compiled D(…) of each head is the compiled value of its closed form; the D lowering is unchanged.

Overlap with the open PRs. #519 (HarmonicNumber) adds its derivative to DERIVATIVES_TABLE, a hunk away from SPECIAL_FUNCTION_PARTIALS; HarmonicNumber is not repeated here. series-decline (the other PR of this pair) touches symbolic/series.ts and one export in symbolic/derivative.ts; no shared lines. #567 (ErfInv(z0, z), the two-operand form) and #560/#562 (kernels) do not edit derivative.ts: with #567 the two-operand ErfInv keeps the inert derivative, as the rule answers one operand only.

Not in this PR: the orthogonal polynomials and Gudermannian are not heads of the engine, and HarmonicNumber is #519; EllipticE(φ|m), EllipticF, EllipticPi and the hypergeometric heads are larger and would go separately.