fix(lock): move the etag when a lock is dropped for having expired - #1291

An explicit unlock moves the file's etag; a lock that goes away on its own
does not. That difference is invisible on the server and decides what sync
clients see, because the desktop only re-reads a file's lock properties when
its etag changed. It short-circuits three times over: an unchanged root etag
skips the sync run, an unchanged directory etag means the children are never
PROPFINDed, and an unchanged file etag yields instruction NONE, which the
sync engine ignores. Lock state is written back only on UPDATE_METADATA.

So a lock that expires is removed here and the client never hears about it.
On Windows the file also keeps FILE_ATTRIBUTE_READONLY and a deny ACL, which
are only reverted from inside a propagation job, so the file stays read-only
indefinitely. Both reporters of #191 and #981 found the same workaround by
themselves: lock and unlock the file in the web UI, which moves the etag
twice and lets the client catch up. #981 confirms both lock tables are empty
while the file is still read-only.

Move the etag on all three paths that drop an expired lock: the cleanup job,
the single read, and the bulk read behind a directory PROPFIND. The file is
resolved without a session, because the job has none.

This does not make the notification channel right. Faking an etag change is
also what produces a conflicted copy when a file is locked while someone has
local edits (#553), so the channel misfires in both directions. Fixing that
properly means giving lock state its own signal, which is a bigger change
than this one.

Green on MariaDB 11.8, PostgreSQL 16 and S3 as primary object store. Each of
the three paths fails the new test without the change.

Signed-off-by: Git'Fellow <[email protected]>

fix(lock): route every expiry removal through removeLocks()

Review of the previous commit found the delete and the etag propagation
paired by convention at three call sites, and an etag moved before the
permission check.

- unlockFile() moved the etag before delegating to unlock(), which is where
  canUnlock() runs, so a refused unlock still told every sync client the file
  had changed. unlock() already moves it once the release succeeds, so the
  early call was both wrong and redundant.
- the single read and the bulk read behind a directory PROPFIND now hand
  their expired locks to removeLocks() instead of repeating its body, which
  leaves one place that removes a lock and moves the etag together.
- a failure to propagate is the fix failing silently, so it is logged at
  warning like the sibling failure in getDeprecatedLocks(), not at debug.

Covers an app owned lock as well: its owner is an app id rather than an
account, so it cannot resolve through an owner's folder and comes from the
mount cache instead. That branch had no test.

Green on MariaDB 11.8, PostgreSQL 16 and S3 as primary object store.

Signed-off-by: Git'Fellow <[email protected]>