Fix scalar-broadcast fill after a non-inclusive axis (scikit-hep/boost-histogram#960)

[NJManganelli]

Problem

In the vectorized fill (detail/fill_n.hpp), a scalar argument is broadcast across an
axis by computing that axis' contribution to the linear index once and adding it to
every entry. The contribution was derived from the change of the first index
(*begin_). When a previous axis had already invalidated some entries — including the
first one — the broadcast axis then invalidated all entries and silently dropped
valid data.

This surfaced downstream as scikit-hep/boost-histogram#960
("Histogram with IntCategory and StrCategory axes can be zeroed by out-of-bounds fill
values"): a non-growing category axis combined with out-of-bounds entries and a
broadcast scalar on a second axis produced a sum of zero. One-at-a-time filling was
always correct; only the array/fill_n path was affected.

Fix

Compute the axis contribution on a fresh index and add it to all entries, leaving
already-invalid entries untouched. The growing and non-growing scalar paths now share
one code path through linearize / linearize_growth, so the "delta from *begin_"
heuristic is gone entirely.

Regression tests compare the vectorized fill against the one-at-a-time reference for
scalar-broadcast-after-non-inclusive-axis, including the growing-axis, zero-point-shift,
and underflow variants (static and dynamic histograms).

Note

The reported bug is in the Python bindings, but the defect is here in core fill_n;
consuming it there is just a submodule bump. Happy to open the companion PR against
scikit-hep/boost-histogram once this lands.

🤖 Root-caused and drafted with Claude Code; reviewed by @NJManganelli.

[NJManganelli]

I asked Claude to match the comment style of the repo, I don't know that it really did (and it left a comment I asked it to remove regarding a now-gone commit that templated a true/false growable axis to no real gain). I'll be ready to have Claude update based on any adversarial review, human feedback, etc.

[HDembinski]

@NJManganelli Looks good, please resolve the comments, though. The AI tends to not clean up after itself, always afraid to remove things. However, all API inside the detail namespace is fair game, even if public.

[henryiii]

Btw, Claude Code added a feature about three days ago /simplify, which runs four agents looking for four classes of simplifications (reuse, simplification, efficiency, altitude), and it works really well. Removing API and comments still are two of the hardest things for AI to do, though. :) If you edit your AGENTS.md (CLAUDE.md should be symlink) to state "the detail module is private, API changes are safe inside it" or something like that, it might be a bit better.

Another thing I like is the prompt: "You are an adversarial reviewer for the new feature in this branch. Do you see any problems? Anything that could be done or written more cleanly? Can you break it?".

Anyway, this fixes #426.

[HDembinski]

The ponytail skill is also good.