Giving up on a resource is spelled the same as a mathematical negative

[Rafael-SOWNet]

What is wrong

AGENTS.md draws a line the code mostly does not: unevaluated means "I could not settle this",
NaN means "this does not exist", and confusing them ships a wrong answer. Resource limits are
where that line is thinnest, because a limit firing and a genuine negative both leave by the same
return null / return false / break.

A survey of Sources/AngouriMath/ for #1035 counted roughly 70 sites where the library gives up
on a resource. Of those, one throws (PrimeFieldPolynomial.cs:400, a representational
precondition rather than a budget) and one recorded which limit fired — GroebnerBudget.Exceeded,
which nothing ever read. Every other site is byte-identical to a mathematical negative.

#1035 gives the library a WorkBudget, a ledger, a BudgetOutcome that names where and why, and
an ambient BudgetRecording scope to read it out, and wires one consumer: Gröbner, whose fifteen
exits are now individually named. This issue is the rest.

The sites where the confusion is visible, not just possible

site	what it does	reading
Functions/Continuous/Solvers/Solvers.Definition.cs:346	can surface a resource-driven null as NaN	"this does not exist" for something never attempted
Functions/Algebra/Polynomials/PolynomialFactoring.cs:355	returns an empty rational-root candidate set when a coefficient exceeds MaxCoefficientToFactor (10⁶)	"no rational roots" for "I did not look"
Functions/Continuous/Limits/AsymptoticSeries.cs:204	returns a truncated series as if complete at MaxExpansionTerms (24)	silently wrong tail
Functions/Algebra/AnalyticalSolving/AnalyticalEquationSolver.cs:337	every limit below the solver converges here on an empty set	indistinguishable from a proven-empty solution set

On the second of these, one thing measured rather than assumed: on 6b93b401, both
(x - 2000000)(x⁴ + x + 1) = 0 and its expanded form return all five roots including 2000000,
and a control with the constant term under the ceiling returns the structurally identical set. So
the ceiling does not currently lose a root through Solve — the defect is in the function's
contract, not yet in an answer. That is the difference between "fix this before it bites" and "this
is a live wrong answer", and it is worth stating rather than leaving to be re-derived.

The fourth is the chokepoint: Solve returning an empty set both for "no solutions" and for "I gave
up" is named in #746's tier-4 assessment
as the place structured failure is absent outside the transformation layer.

Two structural findings from the same survey

Depth counters are [ThreadStatic] while settings are AsyncLocal. So a computation split
across an await keeps its settings and silently resets its depth guards. Eighteen limit-pipeline
guards are in this category.

One setting is doing two jobs. IndefiniteIntegralSolver.cs:106 uses
MathS.Settings.MaxExpansionTermCount — a term-count bound — as a 2000-deep recursion bound for
integration by parts. Changing the setting to control expansion also changes how deep integration
recurses.

Scope

Not one change. In dependency order:

1. Retire the null-as-NaN conversion at Solvers.Definition.cs:346 and give the
   AnalyticalEquationSolver chokepoint a way to distinguish exhausted from empty. This is the one
   with a user-visible payoff and it needs an API decision about what Solve returns.
2. Give the limit pipeline a ledger, and make AsymptoticSeries say its series is truncated.
3. Separate the integration recursion bound from MaxExpansionTermCount.
4. Decide whether depth guards should follow the flow rather than the thread, and make the two
   mechanisms agree.
5. Sweep the remaining sites so each records where it stopped.

Each is separately landable and separately measurable. Step 1 is the one worth doing first.

Acceptance criteria (per step)

• A caller can tell "I could not settle this" from "this does not exist" for that site, and a test
  distinguishes them.
• No input's answer changes silently; anything that does gets a BREAKING-CHANGES.md entry measured
  on a build of each side.
• The common case pays nothing when no budget is set — measured for time and allocation, both
  arms in one process.

Dependencies

Depends on #1035 for WorkBudget / BudgetOutcome / BudgetRecording; do not build a second
mechanism alongside it. Related to
#373 and
#896, neither of which this closes.

[Rafael-SOWNet]

Step 1 is in #1046. Three things from doing it that change what the remaining steps have to do, all
measured on cd0b56b9.

The line reference in the table is to the wrong file. Functions/Continuous/Solvers/Solvers.Definition.cs
is 102 lines long and holds Entity.Solve. Line 346 is in
Functions/Continuous/Limits/Solvers/Solvers.Definition.cs — return MathS.NaN; closing the
two-sided branch of ComputeLimitWithinApproach. It is a limit-pipeline site and belongs with step
2, not with the Solve API decision. Nothing probed shows it live: it is reached only where both
one-sided descents returned a value, and 1/x, abs(x)/x and sin(1/x) at 0 all reach it and all
genuinely have no two-sided limit. Separating a descent's NaN from a proof is what step 2's ledger
is for.

InvertNode's empty returns are a step of their own, and they are genuinely mixed. They produce
the empty answer at AnalyticalEquationSolver.cs:157 and :184, and the three cases below classify
three different ways:

	why it is empty	is { } true?
abs(x) = -1	Invert yielded -e^(i*r_1) provided r_1 in RR and -1 >= 0, whose condition is false	yes — a proof
e^x = 0	Powf.InvertNode yielded ln(0), dropped by Invert's .Where(el => el.IsFinite)	yes — a proof
x! - 6 = 0	Factorialf.InvertNode returns Enumerable.Empty — "TODO: Inverse of factorial not implemented yet"	no — 3 is a root

So neither "the node yielded nothing" nor "the answer came out empty" tells you which it was; only
the override does. Modf, Summationf, Productf, Limitf and Derivativef decline the same way,
two of them with a comment saying declining is the honest answer — and the empty set upstream then
makes it dishonest. Making this addressable means giving InvertNode a way to say "declined" across
its ~30 overrides and teaching Invert's five callers to read it. x! - 6 = 0 is still { } after
#1046.

A related confusion in a shared set operator, not in this survey. SetOperators.IntersectFiniteSetAndSet
keeps an element whose membership in the other operand could not be decided:

"{ 1, 2 } /\ { t : t > y }".ToEntity().InnerSimplified        { 1, 2 } \/ {  }

TryContains(1) on the unsimplified Intersectionf says undecided; on the simplified form it says
yes. That is "I could not decide" spelled as a definite answer, which is this issue's family, and
it is reachable today without any of this. #1046 routes around it at the one call site it would have
made wrong (a conjunction whose sides are not both settled is answered as the conjunction) and leaves
the operator alone, since changing it has repository-wide blast radius.

[Rafael-SOWNet]

Correcting a file reference in the issue body above, which was mine and wrong.

The table says Functions/Continuous/Solvers/Solvers.Definition.cs:346 surfaces a resource-driven
null as NaN. That file is 102 lines long and holds Entity.Solve; it has no line 346. The site is
in a different file of the same name:

Functions/Continuous/Limits/Solvers/Solvers.Definition.cs:346    return MathS.NaN;

which is the limit pipeline, not the solver. So it is not part of step 1 — it belongs with step 2,
the limit pipeline's ledger. #1046 does step 1 without it and says so.

Two further notes from doing step 1, both of which change what a later step should attempt:

The NaN site is not demonstrated live. 1/x, abs(x)/x and sin(1/x) at 0 all reach it, and
all three genuinely have no two-sided limit — so NaN is the right answer for every input tried.
Showing that it can be reached by exhaustion rather than by non-existence needs the work-unit ledger
from #1035 wired into the limit pipeline first. Do not assume the defect is reachable until that
measurement exists; this issue's own opening paragraph is about how easily exhaustion and a
mathematical negative look alike, and that cuts both ways.

InvertNode's empty returns cannot be swept blind, which matters for step 5. They are genuinely
mixed, and the three kinds are not distinguishable from the call site:

input	why it is empty	kind
abs(x) = -1	a provided condition that is false	a proof
e^x = 0	ln(0) dropped as non-finite	a proof
x! - 6 = 0	Factorialf.InvertNode returns nothing at all	a give-up — and 3 is a root

The last one is still { } after #1046, correctly, because step 1 changes the chokepoint and not the
inverters. Separating them means a "declined" channel across roughly 30 overrides and five callers.