Show unlock action for the file owner

[falkloewert]

Fixes #17837

Summary

The "Unlock file" entry was only shown when the current user owns the lock (lockOwnerId == userId). The server also allows the file owner to unlock TYPE_USER locks — OCA\FilesLock\Service\LockService::canUnlock():

if ($request->getType() === ILock::TYPE_USER && $isFileOwner) {
    return;
}

Without this, a stale lock created by another client (e.g. the Text app, lock owner text) cannot be released from the app at all; with the default lock_timeout = -1 it never expires.

Change: FileLockingHelper.canUserUnlockFile() now also accepts file.ownerId == userId.

Known limitation: for group folders and external storage the server deliberately skips the file-owner check (MountProvider allowlist in canUnlock), so the client cannot mirror the rule exactly there; the action can then fail with the existing error snackbar.

🖼️ Screenshots

Not applicable — the only visible difference is an additional entry in the file overflow menu.

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not needed — one added case; existing cases still pass (FileLockingHelperTest, 5 tests)
• 🔙 Backport requests are created or not needed: not needed
• 📅 Milestone is set
• 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?): "Unlock a file locked by another client"

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI — assistant-generated patch, reviewed and tested by me.

[falkloewert]

Updated the patch after testing on a real device (Android 16, Pixel 9 Pro, files_lock 34.0.1, server 34).

Two things the first revision got wrong or missed:

1. App locks are not MANUAL. Text and OnlyOffice lock with TYPE_APP (1), which the client maps to COLLABORATIVE, and for those locks the server returns no lock-owner at all. The old check (lockOwnerId == userId && lockType == MANUAL) could therefore never match. LockService::canUnlock accepts a TYPE_USER unlock request from the file owner for both TYPE_USER and TYPE_APP locks, so the client now mirrors that and only keeps TOKEN locks restricted.

2. The action list was invisible for locked files. FileActionsBottomSheet.handleState() called displayLockInfo() before displayActions(), and displayActions() returns early when fileActionsList is not empty. With a lock present the sheet rendered only the "Locked by …" row and no actions at all — the unlock entry could not have been reached even with the permission check fixed. Reordered.

Verified end-to-end on device: open the actions sheet for a docx locked by OnlyOffice, tap "Unlock file", lock disappears from oc_files_lock.

🤖 Generated with Claude Code