Make e3PIE dispatch on the array module instead of forcing cupy

[ShantanuKodgirwar]

Third in the series building a safety net before performance work. Follows #90, #91.

The problem

e3PIE could not run at all, on either backend. Three independent causes.

1. cupy was hardcoded

initializeReconstructionParams() built the multislice transfer function like this:

ifFalse:
# ... numpy versionifTrue:
importcupyasxp# ... cupy version

So a CPU run produced a cupyH, which then met numpy arrays inside the position loop:

TypeError: Unsupported type <class 'numpy.ndarray'>

On a machine without CuPy it was an ImportError instead. Now uses
getArrayModule(self.reconstruction.probe), like every other engine.

2. betaProbe was set on the wrong object

self.params.betaProbe=0.25# set here
...
self.betaProbe# read here (e3PIE.py:172)

AttributeError: 'e3PIE' object has no attribute 'betaProbe'

Now set on the engine, matching ePIE and the rest.

3. H never moved to the GPU

H was missing from Reconstruction.possible_GPU_fields, so it stayed on the host while
everything else moved to the device.

It is built from __init__, before _checkGPU runs, so it is created on the host either way
and now travels with the rest of the state.

Verification

Each cause was reverted on its own to confirm it is actually load-bearing:

reverted	CPU golden	GPU-vs-CPU
all three (i.e. main today)	✗ TypeError	✗ TypeError
only #3 (H not in GPU fields)	✓	✗ TypeError
only #2 (betaProbe on params)	✗ AttributeError	✗ AttributeError
nothing — this PR	✓	✓

Adds an e3PIE multislice golden (nslice=3), the configuration the transfer function exists
for. Suite goes 30 → 32 passing.

Version

0.2.6 → 0.2.7. This publishes automatically on merge (#92).