Fix new ome-zarr var not being initialised in copy_labels=False branch of apply registration tasks

[jluethi]

@rhornb Discovered a tricky little bug for new OME-Zarr not being correctly initialised and thus the table copying failing (that also used the new_ome_zarr in its add_table call).

I also checked the elastix task and noticed that the copying of tables only works for the reference cycle there, because the variable used is otherwise defined in the write_registered_zarr function. Fixed that there as well now.

[jluethi]

Highlights that we aren't testing all the branches of these tasks I guess. And the linter didn't catch it in the elastix task, because copying of tables only happens in if-clauses (as it depends on the table types)

[rhornb]

@jluethi regarding testing --> absolutely needs to be improved. For the if copying of labels / tables - i would hardcode overwrite to True because in case overwrite_input=False it will not copy them to the new_zarr_url.

[jluethi]

Let's tackle the testing of this later though :)

For the if copying of labels / tables - i would hardcode overwrite to True because in case overwrite_input=False it will not copy them to the new_zarr_url.

I hard-coded overwrite=True for the table writing now. It shouldn't matter, as the apply task always writes to a fresh OME-Zarr that won't have tables yet initially and only replaces the original OME-Zarr with it later if needed. But let's not make the task fail because of a table overwriting block, after it has gone through all the hard work of actually applying a registration :)