Constraint checker can miss negative-consumption roots that satisfy the extended FOCs

[arihantlodha-cmd]

Splitting this out from #1189 at @marcelolafleur's suggestion.

While working on initial-wealth anchoring in #1189, @marcelolafleur found that when the anchor is updated inside the outer loop, the initial cohorts' root-finding can land on infeasible negative-consumption solutions that nonetheless pass the constraint check. From the PR description:

rescaling the households' initial wealth between outer-loop iterations -- even damped -- drives the initial cohorts' root-finding into infeasible negative-consumption roots that satisfy the extended FOCs and pass the constraint checker.

The gist: a root can satisfy the extended FOCs while implying negative consumption, and the constraint checker watches a different consumption object than the one that goes negative, so these roots are not caught. That means an infeasible solution can slip through silently.

This came up as a side effect of the anchoring work rather than something #1189 needs to fix, but it seems worth a dedicated look. @marcelolafleur offered to add more detail here.

[marcelolafleur]

Thanks @arihantlodha-cmd for opening this. I promised detail, and after digging in carefully I think the honest conclusion is that this is narrower than it first looked.

I have only ever seen the problem under one condition: a developer deliberately modifying the solver, which is what I was doing in the experiments that #1189 dropped. In the code as shipped I could not find a way for it to happen, and solved results sit comfortably far from all the bounds involved. The smoothing that makes it possible in principle is doing its job as a search aid and should stay.

So my suggestion is to treat this issue as the written record of the trap (what happened, why, and where it lives) and close it, rather than leave it open as work to be done. If anyone is in that part of household.py anyway, a small guard would be worth folding in: fail the run when a finished solution has negative consumption instead of only printing a message. This issue documents why. But I don't think it justifies standalone work.

@jdebacker your call of course, happy either way.

[arihantlodha-cmd]

thanks for digging in @marcelolafleur, that makes sense. if it only surfaces when someone's deliberately modifying the solver and shipped runs sit well clear of the bounds, then a standing record of the trap plus an optional guard (fail a finished solution with negative consumption instead of only printing) sounds like the right resolution. happy to have this closed as documentation whenever you and @jdebacker prefer.