Fix ParticleHP fission nubar evaluated at wrong energy in const getters

[ibrahmkocaa]

While validating a k-eigenvalue application against the Godiva benchmark
(ICSBEP HEU-MET-FAST-001) I found keff about 6300 pcm low with Geant4 11.4.0.
I traced it to G4ParticleHPParticleYield.

GetMean, GetPrompt and GetDelayed(G4double) are const member functions. Inside
them the member vectors (theSimpleMean, thePrompt, theDelayed) are seen as
const, so the interpolating GetY(G4double), which is not const, is not a viable
overload. The compiler silently converts the energy argument to an int and
calls GetY(G4int) const instead. The yield is then read as the y value of table
point floor(E), with E in internal units. For any reactor-relevant energy this
lands on the first table points, i.e. the thermal nubar (2.4254 for U-235 with
G4NDL 4.7.1), whatever the incident energy. G4ParticleHPFSFissionFS::
SampleNeutronMult takes all fission multiplicities from these getters, so every
ParticleHP fission samples a thermal-valued multiplicity.

A short demonstration with any G4NDL fission FS nubar table:

v.Init(dataStream, CLHEP::eV);      // G4ParticleHPVector v
const G4ParticleHPVector& cv = v;   // what a const member function sees
v.GetY(1.5*MeV);    // 2.58748, interpolated, correct
cv.GetY(1.5*MeV);   // 2.42540, silently GetY(G4int) const, point #1

clang's -Wfloat-conversion warns at exactly these call sites, which is how the
defect stays invisible in a default build.

This patch keeps the change minimal: three const_casts in the header so the
getters reach the existing interpolating lookup again.

Results on Godiva (bare HEU sphere, Shielding physics list, G4NDL 4.7.1,
power iteration with 5000 neutrons per generation, 120 generations, 30
inactive, same application code in both rows):

Configuration	keff	measured nubar(E)
11.4.0 unpatched	0.9362 +/- 0.0024	flat at ~2.43 in all bins
11.4.0 with this patch	0.9969 +/- 0.0025	2.42 to 2.86, rising with E
OpenMC 0.15.3, same model	1.0003 +/- 0.0010	(ENDF/B-VII.1)
ICSBEP benchmark value	1.0000 +/- 0.0010

The leakage fraction agrees between the two codes (0.570 in Geant4, 0.5728 in
OpenMC), so the discrepancy is confined to the fission multiplicity. I also
built this branch as-is (11.5.0.beta plus this commit) from scratch and reran
the same Godiva case against it: 0.9969 +/- 0.0025, matching the patched
11.4.0 result. Thermal
systems are barely affected because the wrongly returned value happens to be
the thermal one, which would explain why this went unnoticed. Criticality
validations published with Geant4 9.5 and 10.x do not show the deficit, so the
regression probably entered with the const-correctness rework of particle_hp.

Two remarks for the maintainers. The const_cast reaches the existing non-const
path; GetXsec(G4double) updates internal lookup state, so this path is exactly
as thread-safe (or not) as it was before. And a more durable fix would be a
const interpolating overload in G4ParticleHPVector, possibly together with
renaming the index-based GetY(G4int), so that an implicit double to int
conversion can never shadow the energy lookup again. I kept both out of this
PR to leave it a one-file change.

I will file a problem report on Bugzilla and link it here.

[ibrahmkocaa]

Problem report filed on Bugzilla: https://bugzilla-geant4.kek.jp/show_bug.cgi?id=2745