## Validate relative radius before passing a ball midpoint to quadrature

What happened: T647's independent integral checker evaluated K_0(t) with
Sage's ComplexBallField at roughly 300 bits, then took its midpoint for
mpmath quadrature. At t=100 the midpoint differed from mpmath's K_0(100) by
about 2.7 percent, although the ball enclosure itself did not make that
accuracy claim. The nonzero control integral of t K_0(t) over (0,infinity),
whose value is 1, missed by 3.28464939547e-23 in a 70-digit quadrature. The
segment [20,330] accounted for that error; the other segments agreed to about
70 digits. Cancellation in this range can leave very wide enclosures at a
fixed working precision. This was a checker failure, not evidence against
the determinant product formulas or the correctness of Arb's enclosure.

What the skill says now: a ball must be finite and its radius small enough
for agreement to mean anything; wrapping a midpoint does not certify it.

What it should say: when passing ball midpoints into a nonrigorous numerical
algorithm, first require each ball's relative radius to meet the precision
that the algorithm expects. Recheck this at every evaluation point; special
functions can lose many bits only in an intermediate argument range. Increase
working precision until the bound meets that condition, and keep the final
quadrature labelled heuristic unless integration error is also certified.

Evidence: quadrature_diagnostic.py and quadrature-diagnostic.txt in this run's
work directory. checks.py now requires positive finite Bessel balls with
relative radius below 10^(-dps-12), doubling the field precision when needed.
It runs the known controls before the determinant comparisons. This is a
proposed clarification only; no skill or pipeline file was changed.