3f9b1a28

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

add LU-h sampling profiles and verify inverse densities

Named standalone cut channels accept radial_profile="lu_h" or an explicit
log-logistic proposal table. Compile the normalized mixture and dual
derivatives during warmup using the actual runtime h settings. Keep the
root-independent broad radial component, per-name profiles and maximum raised
cut order in the existing canonical catalogue and map owners.

Evaluate radial inverse densities at the supplied point and check selected
forward/inverse consistency against the native stability budget. Extend the
physical kite/cut, raised-derivative and saved-state reference gates. Independent
h normalization tests also correct the pre-existing power-15/16 coefficients
in both scalar and dual poly_left_right_exponential evaluators.

Validation: 177 selected core tests pass across broad/focused runs; both
physical summed/explicit and saved-state Gaussian/moment API regressions pass.
The saved-state gate evaluates 8192 points per fixture and passed in 103.313s;
give that test a specific five-minute default nextest timeout. cargo fmt,
core/API test checks, Python-feature test checking and clippy pass, with no
warnings on changed lines. Detailed commands and limitations are recorded in
docs/research/advanced_sampling/LU_H_MATCHED_SAMPLING.md.

The optional profile changes serialized named channel definitions; old saved
definition compatibility is not guaranteed. No GL638 variance improvement is
claimed yet. Its power-3 physical h and threshold metadata remain unchanged.

User prompts:

Continue as planned, but now that you'll have a sampling density with a variable aligned directly with the "distance to the cutkosy cut", then it'd be natural to choose a sampling density for that variable whose jacobian is the inverse of the Cutkosky cut h-function! Of course, the CDF arising from the h-function is not exactly invertible, but one can use a density for that variable which yields a jacobian close to that requirement (i.e. approximates it "well enough"). Continue your orchestration as planned, but launch a subagent on that topic and based on its findings, edit the goal / plan and research documents to include that element too.

Continue as planned, but re-read the plan, and establish how to best orchestrate progress on both front of amplitude surface advanced sampling, but also the overall goal of cross-section advanced sampling, that must eventually apply to GL638 and demonstrate improvement there.

(continue as planned, but remember that for being able to quickly generate states for testing, specifying ot one orientation may help. But ultimately, things must be tested end-to-end on all orientations)

(oh and I forgot, you should commit+push regularly at good milestones in a new feature branch `advanced_sampling`, which does not exist yet )

Add to do all git commit and push from the user ValentinHirschi with email valentin.hirschi@gmail.com
Also explicitly add to the plan that this is a hard task and you should consult the existing research you did already often (specifiy relevant markdown) and complement it when needed and use many subagents to do implementation slices, code audit, tests and research. As the main agents you should mostly act as an orchestrator, so as to not pollute your context.

Timeline