e30d799e

By: ValentinHirschi <valentin.hirschi@gmail.com>

fix local UV counterterms and prepare validation candidate

Preserve factorized direct and projected UV constructions and exact source
ownership; fix CFF scalar/contact normalization and integrated UV handling.
Reduce repeated alias and capacity-envelope work, simplify the nonzero M input
contract, and add the guarded release scalar matrix target. Refresh generated
Nix metadata and remove temporary handoff material from the tracked tree.

This is a validation candidate for a draft PR, not the ALL_GREEN milestone.
Strict release check, Clippy and formatting passed. The fresh 166-case scalar
matrix, 54 focused regressions, full just test_gammaloop and remote CI remain
pending. Regenerate saved states/evaluator archives for the changed layouts.
Phase work and extended physical studies remain deferred.

User request (verbatim):

Assign yourself the goal in:
```
./HANDOFF_REMOVE_FOR_PR/HANDOFF_GOAL.md
```

which instructs you to start things off by fixing:
```
./HANDOFF_REMOVE_FOR_PR/HANDOFF_T2_DISCREPANCY.md
```

Note that this is a hard problem in a complicated code, so use subagents to compartimentalise the work and context and work systematically towards fixing the bugs.

Also read all contents of the folder `./HANDOFF_REMOVE_FOR_PR` to benefit from all the existing research already performed by a weaker agent.

Useful commands here in general are `output standalone --json` to be able to see expressions used in plain sight, and also `uv_profile` to test proper subtraction of UV singularities and of course various temporary edits of the code or custom tests to dissect problematic expressions to find MREs of them facilitating the understanding of the issues

Checkpoint and continuation instruction (verbatim):

Continue as planned and make sure that we can get `just test_gammaloop` complete without skipped test and within 30 GB of RAM. Once all green continue with the plan, and also the audit/review/refactor of the code related to local UV CTs from 3D and 4D as it is complicated and needs to be extremely clean, understandable, with the right amount of factorization, without any legacy hack, some comments where it's hard to understand, so as to make its future maintenance and extensions easier.
Make sure this clean version with green test is pushed with "ALL_GREEN" on the remote and the continue and complete the goal with the study of ddx and ttx.

Don't let my need for approval stop you again. If you must take a decision that you think is within the scope of my approval, triple-check that you really need it (not like point 2. before) and then choose the answer for yourself, and just write it in "PENDING_APPROVALS.md" and continue. I'll periodically come and ask you about that file's content, but no longer wait for me, just make a decision and proceed towards the goal completion.

Requested scalar target (verbatim):

Continue as planned, but I want you to add to the justfile a new target for `just test_LU_scalar_xs` (with `--release` compilation by default), which would match exactly the run you're doing now.

Requested fail-fast behavior (verbatim):

(ah and also in --fail-fast mode on this target).
Scalar generation optimization instruction (verbatim):

Continue as planned, but what are you doing now, can you try to finish the scalar LU matrix?
Also if you can find anyway to reduce the RAM usage and increase generation speed of these scalar cross-section you should do it now. while you wait for result. You had a pending study and proposal for an improvement that you can now look into (since we now know that `just test_gammaloop` is all green).
Explicit summed function-map request (verbatim):

I think that it may be faster to have the scalar matrix run with `summed_functionmap = false`, it will speed up the 3D direct route, and the runtime performance is irrelevant for this test.

Phase deferral instruction (verbatim):

No there is a phase issue/ambiguity in gammaloop for now (in part because of the complex conjugation on the right-hand-side of the cut still needs to be implemented). So for now keep the tests as they are and do not address the phase, we'll do that later, let's not delay the ALL\_GREEN push.

Additional user prompt:
I think the memory watchdog runner is not counting ram properly change it to follow just that process tree.
Also when rerunning can you start from GL16 directly?

User request:
Oh, interesting, indeed getting the rank envelope should be quick and without expanding the numerator. There is no reason that it should be slow. Can you improve it and make this step faster?

User request:
Ok, and more in general profile GL16 to see if you can have easy wins to make its generation faster.

Strict factorization clarification (verbatim):

But when does the production lane ever does this check and why does it do that and why does it need to know this? In order to know this there are many fast ways, simplify looking at the residue map key directly, or even just asking from symbolica the list of variables present in an expression (there is a fast function for this already in Symbolica). IN NO CASE CAN THE NUMERATOR EVER BE EXPANDED!

Unconditional M parameter simplification (verbatim):

I would keep this simpler and just *always* add M to the parameters given in input to the evaluators. It does not cost anything really.

Immediate implementation approval (verbatim):

No I approve of this change already now! What is left for me to address in PENDING_APPROVALS?

Final completion scope (verbatim):

Ok continue as planned now, trying to finish this damn scalar LU matrix, and only looking for improvement to the code if you can find relatively non-invasive cheap wins. The core objective is getting to ALL_GREEN commit and push merge-ready state of the corresponding PR. Then stop yourself and deem the goal achieved (if there does not seem to be any gross oversight w.r.t what is in it).

Timeline