fix(#125): fail closed on degenerate BCa intervals

[marcohost33-maker]

Problem

A noise-free / numerically degenerate parametric bootstrap can return an exactly zero-width BCa interval. The arithmetic is internally consistent but the public meaning is unsafe: the resampling model has no measurable spread, so (x, x) reads as perfect uncertainty resolution rather than uncertainty unavailable.

Fix

bca_ci now treats degeneracy per parameter, not per fit:

• an all-identical bootstrap distribution returns (NaN, NaN) for that parameter with a RuntimeWarning;
• if the BCa adjusted quantiles still collapse to an exactly zero-width interval despite non-identical samples, that parameter is likewise withheld;
• independent non-degenerate parameters in the same fit remain reportable.

No arbitrary noise floor or scale threshold is introduced.

Controls

New regressions cover:

1. identical bootstrap values -> unavailable, not zero width;
2. one degenerate + one informative parameter -> only the degenerate one is withheld;
3. ordinary noisy bootstrap -> finite non-zero-width interval;
4. non-identical but highly tied distribution whose adjusted BCa endpoints collapse -> withheld at the claim boundary.

External validation

SciPy's current scipy.stats.bootstrap(method='BCa') documents DegenerateDataWarning and notes that BCa confidence-interval elements may be NaN when the bootstrap distribution is degenerate. This PR adopts the same fail-closed interpretation rather than inventing a finite uncertainty floor.

Stacked on #134 because that branch contains the preceding GLS amplitude-scale fix; this PR changes only bootstrap uncertainty semantics.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[marcohost33-maker]

Exact-head verification is complete on b46daa8ca0642beb836783247ce47960cb7411d3: CI, ci-reusable-pilot, Quality Contract, QuTiP cross-checks, and CodeQL all completed successfully. This validates the #125 slice itself. The fix remains stacked on #134, so merge/integration still depends on the underlying stack; verification PR #144 is no longer needed.

[marcohost33-maker]

Status 2026-09-07 — matrix-tested at head; deepest base in the stack

head b46daa8c -> check-runs: 13, test-matrix jobs: 5, non-success: 0
base          -> chatgpt/issue-124-residual-scaling  (= the head branch of #134)
vs pr107-fix@bac5fe0d : 13 commits missing here, 4 unique to this PR
mergeStateStatus: CLEAN

The 13 runs come from the now-closed exact-head verification PR #144, which carried this SHA against main. Without that surface there would be none: ci.yml triggers on push: [main, "claude/**"] and pull_request: branches: [main], and a chatgpt/* branch based on another chatgpt/* branch falls through both. So this is not one of the CI-blind PRs — #131 and #147 are.

This PR sits two levels deep: #143 -> chatgpt/issue-124-residual-scaling (#134) -> pr107-fix (#121) -> main. CLEAN here means clean against #134's head, which is itself 13 commits behind pr107-fix. It is not a statement about main.

No issue band added: the base is not main, so Closes #125 would be structurally inert.

What Marco has to decide

Nothing to fix on this branch itself. It moves only after #121 lands and #134 is rebased onto it — and the rebase will invalidate b46daa8c and with it the matrix evidence above, which then has to be re-earned. Deciding the ci.yml trigger question once (extend to chatgpt/** and non-main bases) would spare six PRs a second round of verification surfaces.

Read-only measurement. No push, no merge, no rebase, no re-run, nothing resolved.