test: grad in SQL under awkward names, and SGD loops in SQL (M4 8)

[alxmrs]

Stacked on #91. This PR tests the adapter's SQL surface (ad::sql, ad::sql_all) the way users will reach it.

What it adds

• names: grad(loss, t.col) must equal the program's gradient in each of these setups:
  • the table read as s1.t or "T t", while a decoy under its old name holds different values, so reading the wrong table can't pass by coincidence;
  • a CTE shadowing the table's name;
  • the call inside a subquery or a later CTE;
  • two losses in one statement (grad(2L) − 2·grad(L) = 0);
  • user tables named like ddx's steps (value, saved_0, grad_0_w, …), which must come through untouched.
• train: three SGD steps written in SQL, one statement per table through sql_all. Each must move θ to exactly θ − lr·∇L as a fresh ad::grad program computes it. Some step along −∇L must lower a smooth loss (kinked losses are exempt). The context must be clean after every step.
• Stricter oracle: a NaN or infinite gradient where the loss is finite and smooth along the direction is now a failure. It used to be skipped.
• A refusal only the SQL surface makes (it plans SELECT * FROM loss, a slightly different plan from the program API's) is tallied as coverage, not failed.

What it found

About 4,900 cases:

• A table whose name has a capital has no gradient in SQL. Pinned in ad_findings.rs. The gradient step is named after the table (…_grad_0_W). ctx.register_table folds that unquoted name to lower case, and ad::sql then reads it back quoted, so it isn't found. Any "Weights"-style table name hits this. Only the soak tries this variant until it's fixed, so the PR gate stays green.
• The MAX recomputation bug from test: ties, NULLs, extreme values and big tables in the v2 soak (M4 7) #91 also produces NaN and inf, not just zeros: the even split divides by zero attaining rows. The stricter check catches these now.
• Minor, noted rather than pinned: with NaN or infinite data, ddx-core's quotient-rule expression evaluates ∞/∞ = NaN where the partial's limit is 0. That's a v1 expression-form limit only infinite inputs reach, and those cases are exempt from the NaN check.

Nothing wrong in schema-qualified names, shadowing CTEs, calls in subqueries or later CTEs, two losses per statement, look-alike user tables, or the SGD loop itself.

Next and last in the stack: mutation testing of ddx-ad, to measure how fast this harness catches seeded bugs.

🤖 Generated with Claude Code

https://claude.ai/code/session_012NE18ox5ivwTc7ZSbHZUGu

[alxmrs]

The capitals finding is fixed (#74: gradient step names are lower case). It's un-ignored, and the names group now tries quoted capitals in the PR gate too, not only in the soak.

The ∞/∞ note turned out to be fixable, so the NaN/∞ exemption is narrower now. ddx-core's quotient rule is (du − (u/v)·dv)/v in #96, and a negative power is written as a division in #97. Infinite data is compared again.

Soaks of the fixed stack then showed where a NaN or ∞ gradient is reverse mode's own answer (JAX gives the same), and those points are now screened:

• the loss doesn't move beyond rounding along the direction: sqrt(0) or tanh(b·∞) gives 0 · ∞ (seeds 811, 500192);
• NaN over infinite data (600421);
• a derivative beyond √f64::MAX (2000728);
• tiny values, where dividing by a parameter near 1e-160 overflows the chain rule (2400607).

Other changes on this branch:

• Descent check: now counts the head's MAX/MIN as a kink (1900692).
• Names check: allows 1e-6 relative error in huge mode, where sin(SUM(v)) turns an ulp of a sum near 1e9 into about 1e-7 (1900495).
• New pin: ad_findings.rs pins power(v, 0.5) at v = 0, which failed a program ddx had accepted until fix(ddx-core): write a negative power as a division #97.

🤖 Generated with Claude Code

[alxmrs]

LGTM