DualArray::resize leaves the grown device tail undefined (pinned build), silently NaN-poisoning contact forces

[DanNegrut]

Related to #71, and complementary to @Ward-Vandepitte's #72, which identified this same root cause
three weeks earlier and which I had not seen when I prepared this. #72 has the better account of
how the corruption becomes a stall: a NaN quaternion makes every bin-range comparison in
getNumberOfBinsEachSphereTouches evaluate false, so the sphere is assigned the entire bin grid
and contact detection degenerates into an all-pairs sweep. That is the link I was missing.

This PR is one change at a different level of the stack, and touches no file that #72 touches.

#72 fixes the two symptomatic call sites, with an explicit cudaMemset of
contactPointGeometryA/B after each DEME_DUAL_ARRAY_RESIZE, plus two defensive layers (a loud
abort on non-finite bin coordinates, and a zero-force early-out in forceToAngAcc that also
avoids the MOI and quaternion loads for the majority of entries). Its own comment states the
container contract that forces the workaround: "DualArray::resize(n, val) fills host values only".

This PR fixes that contract instead. In the pinned-memory build (DEME_USE_MANAGED_ARRAYS
off), resizeDevice never initialises grown elements: on reallocation it copies forward only the
pre-existing data, and when capacity already suffices it returns without touching memory. So
device elements [old_size, n) are undefined on both growth paths, in both resize flavors. The
fix captures the old size and pushes exactly the grown range host-to-device through the class's
own toDevice(start, n). Device data in [0, old_size) is never overwritten, so arrays whose
device copy is authoritative mid-simulation are unaffected. The managed variant needs no code
change; only its copy-pasted comment is corrected.

The reason to do both: 104 call sites pass a fill value in the reasonable belief that it defines
the new elements. #72 makes that true for the two arrays that were observed to bite. Any other
DualArray that grows and is read on device before being written keeps the defect, and the next
occurrence would present as a fresh mystery rather than as this known one. If #72 lands first its
memsets become redundant but remain harmless, and its two defensive layers keep their independent
value.

Measurements, on a settling bed of 3,615 spheres, one RTX 5090, CUDA 12.8, commit 0fdc6de1:

build	total initcheck errors	of which device-side reads
0fdc6de1 async	23,357 and 15,226 in two runs	14,893 in the run counted by class
0fdc6de1 synchronous + user expand factor	87,069	not separated by class
with this fix, async / sync+margin / sync-no-margin	20, 20, 20	0, 0, 0

Stock counts vary run to run because how much the contact arrays grow mid-run depends on
scheduling; the reproducible part is the contrast with zero. Blocking growth by a different route,
an 8x initial contact buffer, independently drove failures from 6/40 to 0/40 (Fisher exact
p = 0.026), which confirms the mechanism without touching this code. Settled-bed physics is
unchanged within resolution: 41 interleaved runs, solid fraction difference 1.2 sigma against a
~0.3% single-run scatter.

Two disclosures. The residual 20 errors in every fixed configuration are a separate pre-existing
host-side defect, DEMSolverScratchData::allocateScratchSpace handing cudaMemcpy a partly
written pinned buffer; it appears in configurations that never fail, so it is not this mechanism,
and this change neither causes nor closes it. And memcheck surfaced, once in ten completed runs of
the fixed build and never in eleven of stock, an out-of-bounds read in rearrangeContactWildcards
reached through migrateEnduringContacts. Fisher exact on 1/10 against 0/11 is p = 0.48, so that
comparison is inconclusive rather than exonerating. I attribute it elsewhere on source grounds
rather than statistical ones: that array is dispensed by DeviceVectorPool, built on
DeviceArray, while this change touches DualArray only, and where it does touch the wildcard
arrays it makes their grown tails defined rather than undefined, which cannot manufacture an
out-of-range index. Reported separately rather than buried here.

Full mechanism, evidence and the preconditions the tail-push relies on are in the commit bodies.