Fix/propagator close errors

[butonic]

Four places in the two copies of decomposedfs throw away the error returned when
releasing a parent node's lock during treetime/treesize propagation. This makes
them observable.

Why

Propagation opens the parent's lock file, and both copies have code that tries
to report a failing close/release — but the reporting is inert:

pkg/storage/utils/decomposedfs (legacy copy: ocis driver, datagateway/ocs)

• tree/propagator/sync.go — propagateItem had unnamed results, so the deferred
  err = cerr assigned to the local err declared by f, err := lockedfile.OpenFile(...)
  after the return values had already been fixed. The error never reached the caller,
  so the comment ("always log error if closing node fails") and the if err == nil
  guard were aspirational. Naming the results makes the close error reach Propagate,
  which logs it and returns it. (f, err := had to become f, err = because named
  results live in the function body scope, leaving no new variable for :=.)
• tree/propagator/async.go — the same assignment sits in propagate, which returns
  nothing, so it could never be observed. Replaced with the log the sibling early-release
  path already emits (Failed to close node and release lock).

pkg/storage/pkg/decomposedfs (maintained fork: posix, decomposed, decomposeds3)

• tree/propagator/sync.go and tree/propagator/async.go — defer func() { _ = unlock() }()
  discards the error from closing the .mlock file (xattrs / messagepack / hybrid backends).
• tree/propagator/async.go early release — _ = unlock() likewise discarded it. The
  os.ErrClosed filter is load-bearing here: the async propagator releases the lock early,
  so the deferred unlock always runs a second time and sees ErrClosed on the happy path.

Behaviour change

• utils copy, sync propagation: a failed lock-file close now aborts the parent walk and
  returns an error from Propagate, where previously the walk continued silently. Expect more
  surfaced errors in the operations that trigger propagation; the underlying cause (I/O /
  metadata failure) was already there, just invisible.
• everything else is log-only — no control flow change.

Why the pkg fork logs instead of returning

The lock file is created empty and never written, so there are no dirty pages to lose — a
failing close signals an I/O error on the handle, not lost data. Aborting propagation (and
failing the upload/copy that triggered it) would be out of proportion, so the error is logged.
The utils copy keeps returning it because that code path was already written to do so.