Feature request, write_element does not materialize computation in in-memory SpatialData Object

When using sdata.write_element(), the Dask computation remains lazy in the in-memory SpatialData object, when SpatialData object is backed by disk.
So each time we do sdata.write_element(...), we need to call spatialdata.read_zarr(sdata.path).

See example:

import os
from tempfile import tempdir

import dask.array as da
from spatialdata import SpatialData, read_zarr
from spatialdata.models import Image2DModel

#1) creation of a spatialdata object backed by a zarr store

sdata = SpatialData()

arr =  da.random.random((1, 1000, 2000), chunks=(1, 500, 500))

sdata[ "image" ] = Image2DModel.parse( arr, dims = ( "c" , "y", "x" ) )

sdata.write( os.path.join( tempdir, "sdata.zarr" ) )

#2) read it back from the zarr store
sdata = read_zarr( sdata.path )

#3) Do something with the data, and save to a new slot
arr = sdata[ "image" ].data *2

sdata[ "image_mul" ] = Image2DModel.parse( arr, dims = ( "c", "y", "x" ) )

# this triggers computation, similar as .to_zarr(...)
sdata.write_element( "image_mul" )

for _, layer in sdata[ "image_mul" ].data.__dask_graph__().layers.items():
    if not layer.is_materialized():
        print( layer )  # layer 'mul-...' is not materialized, i.e. computation is still lazy in the in memory sdata object, similar behaviour as `dask.array.to_zarr`

# if we load back from the zarr store, we see that layer 'mul-...' is indeed materialized, similar behaviour as `dask.array.from_zarr`
sdata=read_zarr( sdata.path )
for _, layer in sdata[ "image_mul" ].data.__dask_graph__().layers.items():
    if not layer.is_materialized():
        print( layer )

Although this is in line with e.g. dask.array.to_zarr and dask.array.from_zarr, it would be a nice feature to have an extra parameter inplace, e.g. sdata.write_element(..., inplace=True), which takes care of reloading from the zarr store. Ideally this would only reload the element that was written to disk, not the complete Spatialdata Zarr store, which can be slow when there are lot of tables or shapes, as these are always loaded in-memory.

Also see https://github.com/saeyslab/harpy/issues/90 for additional context.

Start at the SpatialData.write_element() entry point and compare its behavior with read_zarr() and Dask's to_zarr/from_zarr behavior. Define how an inplace=True option should update only the written element, then add coverage showing that the in-memory element's computation is materialized without reloading the complete SpatialData store.