Invalidations 4/6: reach reduction hooks through Base internals

[asinghvi17]

Part 4/6, on #340. Supersedes #335; thanks @Beforerr.

Moves the reductions off public Base methods. #316's backend hooks stay reachable without invalidating Base code:

• any/all: on 1.11+, hook Base._any/_all(f, ::AbstractDiskArray, dims). On 1.10, keep the public any(f::Function, a), because the _any hook would invalidate LinearAlgebra code there. Per-chunk short-circuiting is unchanged.
• sum, prod, maximum, minimum, extrema and count: drop ; kwargs... from the public methods. dims and init reach each reduction's own diskarrays_*_impl through Base's internal _sum and friends. Tests assert this for every form.
• Fixes init= for these reductions, which threw a MethodError on Add options to extend compute backends #316.

uinvalidated after using DiskArrays (#340 → this PR):

session	Julia 1.13	Julia 1.12
clean	153 → 151	503 → 141
CairoMakie session	2826 → 2830	3238 → 3242
many packages loaded	1705 → 1709	1765 → 1769
DataFrames session	807 → 786	1506 → 1111

The 1.12 clean drop comes from a compiler call site that 1.13 already fixes (JuliaLang/julia#62491). The CairoMakie and many-packages rows rise by 4 because the whole-array init hooks collide with GeometryBasics' maximum(f, faces; init=0).

🤖 Generated with Claude Code

https://claude.ai/code/session_019Dfq6aDr3GqA8w61TsvMsc

[mkitti]

Looks good to me. The approach is sound and I could not break it, but it leans on Base internals, so see comment 1.

What I ran

• The full test suite on Julia 1.10, 1.11, 1.12 and 1.13: all pass.
• A battery of 36 reduction forms against an in-memory array, on #340 and on this PR, on 1.13 and 1.10: sum/prod/maximum/minimum/extrema/count/any/all, each with a function, dims, init and combinations, a callable struct, a view, mapreduce and reduce.
  • Values and read counts are identical to #340 everywhere except the 8 init= forms (sum, sum(f, …), sum with dims+init, prod, maximum, maximum(f, …), minimum with dims+init, count). Those throw MethodError: no method matching diskarrays_*_impl on #340 and are correct with 16 reads here, so the claimed fix is real.
  • 1.10 and 1.13 give identical output for every case on this PR.
  • Short-circuiting is preserved: all(<(-90), a) reads 1 of 16 chunks, any(>(250), a) reads 13.
• uinvalidated after using DiskArrays on 1.13, #340 → this PR: 574 → 572 in a clean session and 1003 → 982 with DataFrames loaded.

Comments

1. It depends on Base internals. The PR adds methods to Base._sum, _prod, _minimum, _maximum, _extrema, _any, _all, _count, and a Core.kwcall method for the init whole-array case. All exist on 1.10–1.13, but nothing guarantees they keep their signatures. The per-form hook tests would fail loudly if one changed, and the nightly job in the CI matrix is the early warning; maybe say that in a comment next to the Core.kwcall block, since it is the least obvious one.
2. The init hooks cost +4 invalidations in Makie-like sessions (GeometryBasics' maximum(f, faces; init=0)). The description and backend.md both say so, which I appreciate. The trade is reasonable because init= was throwing before, but if that count ever matters, that block is the one to gate.
3. FYI, not this PR: Project.toml declares julia = "1.9", but on 1.9.4 maximum(a; dims=1) and sum(view(a, …)) already throw UndefVarError: rm_singleton_indices on main and here (CI starts at 1.10). The init forms work on 1.9 with this PR.
4. Docs: the table makes it clear that a callable struct f reaches diskarrays_mapreduce_impl rather than the per-reduction hook, and that on 1.10 non-Function callables iterate. That is a real inconsistency between Function and callable f, and it is documented. A one-line CHANGELOG entry (there is none) would help backend authors, since the dims=:, kwargs... hook signatures changed.

Not blocking.