fix: wrong nuclide codes for ground-state nuclides + two crashes

[steps-re]

Three independent fixes found while auditing the depletion code.

1. Ground-state nuclides get the wrong ZA code (serpent_depcode.py, _zam_to_nuclide_code)

def _zam_to_nuclide_code(self, Z, a, m):
    nuc_code = Z * 1000
    if m != 0:
        ...
    return nuc_code

For a ground-state nuclide (m == 0) the mass number a is never added, so e.g. U-235 (Z=92, a=235) encodes as 92000 instead of 92235. The inverse method _nuclide_code_to_zam recovers a = nuc_code % 1000, confirming the encoding must be Z*1000 + a.

I add a only in the m == 0 branch. The metastable branches are intentionally left untouched: the serpent branch's ((a/100)-3)*100 already carries an a-dependent offset, and the nndc branch follows its own convention — I didn't want to disturb conventions I'm not certain about. Happy to extend if the metastable paths also need a.

2. .pop() on a NumPy array (results.py)

nuc_comp_br = material.before_reproc.comp[:, nuc_map[nuc]]   # ndarray
nuc_comp_0 = nuc_comp_br.pop(0)                              # AttributeError

comp[:, ...] is a NumPy array with no .pop. The sibling method (_collect_material_properties) calls .tolist() first; added it here for both before/after arrays.

3. == instead of = (openmc_depcode.py)

else:
    exec_path == (Path(...) / exec_path).resolve()

The non-default depletion-script branch compares instead of assigns, so the resolved path is computed and discarded and exec_path is never updated. Changed to =.

Testing

Localized fixes verified against the surrounding code; I didn't run the suite locally (needs a Serpent/OpenMC environment). Glad to adjust to your conventions.