fix: make the locking model consistent across every access path

[solracsf]

Both a Fix and Feature

Feel free to review each commit.

The app decides who may lock, write and release a lock separately in each entry point, and the answers disagree: the same user gets a different result through OCS, X-User-Lock, native WebDAV and the PHP API. This builds one persistence model and one policy, then moves every path onto it. Best reviewed commit by commit.

The first three commits are #1269, including the federated display name fix from review there. Please ignore them here; this branch gets rebased once that lands.

feat(db) one lock per file and one absolute expiry. There was no uniqueness on file_id and acquisition read before it wrote, so two requests could both take a lock on the same file (reproduced with two processes, ten rounds, every round). Expiry existed twice over, as a ttl counted from creation for the ETA and as a creation-age query for the cleanup, so the job deleted locks that clients had refreshed and still believed they held. Adds a unique index, with a migration that reconciles the duplicates an existing installation may already hold before adding it, insert-first acquisition, and expires_at as the single expiry.

feat(policy) one authorization decision. The file-owner override was keyed on a hard-coded list of mount provider classes, so any provider not on that list granted the override to whoever happened to be looking. A token lock could only be released by presenting the token, which the server-side API cannot do, so an app could not clear its own user's stale client lock. And possession of the token was the whole credential, although the token is published to everyone who can read the file. Now a user lock belongs to its user, an app lock to the app's lock scope, and a token lock to the token together with the principal it was issued for.

feat(storage) enforce by file identity. The wrapper rebuilt a path inside the user's home folder, so it silently enforced nothing on group and team folders, external storages, or any custom mount. It now resolves the file through the wrapped storage's own cache, refuses a folder delete or move that would take a locked file with it, and runs ahead of the trash bin so a refused delete cannot have moved the file already.

feat(dav) rebuild the native adapter. Lock creation was a create-then-update, so a rejected second write left behind a row owned by a random token. The client's <D:owner> text was stored and shown to everyone as the lock owner, a missing Timeout header produced a lock that never expires, Sabre's token check authorised writes on possession alone, the requester's own user lock was hidden from the protocol, and errors came back as 500.

fix(api) OCS and CLI contracts. Status codes for ordinary client mistakes, lockType honoured on unlock, forced unlock by file id so it no longer needs the lock owner to still have access, and the README brought in line.

test collaborative multi-client churn. The suite only ever exercised one actor at a time, so nothing covered what a real deployment does to a lock: several people editing, renaming, moving and deleting the same tree from the browser, the sync client and the mobile apps at once. Six cases added. Through a real Sabre server: a manually locked file keeps its lock when its holder renames it and is still refused to the other user at the new path; only the client holding a token lock moves the file, so the same user's own browser is refused until that client releases it; a client that never sends UNLOCK stops holding the file for the rest of the team once the configured timeout passes; and directory listings follow locks other clients take and release, which is the only coverage LockPlugin::cacheDirectory() and LockService::getLockForNodeIds() have. At the storage level: a move to another storage strands no lock row, and a second user cannot move a held file out onto a mount of their own.

Two things worth an opinion:

• Releasing a token lock now also needs permission to write the file. The token stays readable through PROPFIND, which RFC 4918 6.5 allows and the desktop client relies on; what changed is that possession alone is no longer enough, as 6.4 asks. Before this, a read-only share recipient could read the token and drop a colleague's lock.
• A collection LOCK still protects only the collection itself, not its members. That is unchanged and now documented; the litmus patch in this repo already disables the member assertions.

Verified: the suite (87 tests) on MariaDB 11.8, PostgreSQL 16, and SQLite with S3 as primary object store; the earlier 80-test state also on Oracle; litmus basic, copymove, props and locks, 94 of 94; psalm, cs-fixer and rector clean; the two-process race repeated; and every commit green on its own against MariaDB.