Text app locks files, and doesn't release the lock, when invoked through the desktop client

Describe the bug

Under GNOME, with the nautilus-nextcloud extension, it is possible to open the Text app directly from the local file manager. The Text app locks the file, which the desktop client turns read-only locally, but when the browser window is closed, the lock is not released, and the local file remains read-only.

The lock is indefinite, and there is no way to unlock the file, except maybe through the web-interface, but this workflow doesn't use the web-interface.

To Reproduce

1. Open a synced folder in GNOME Files
2. Right-click on a markdown file, select Nextcloud, and Open in browser.
3. Make a change to the file in the new browser window.
4. The local file now turns read-only.
5. Close the browser windows.
6. The local file remains read-only.

Expected behaviour

The file should be unlocked when the editor is closed, and the local file should return to its previous permissions.

Server details:

• Nextcloud version: 34.0.0
• PHP Version: 8.4.21
• Database: MariaDB 11.8.6

Client details:

• OS: Debian Trixie
• Browser: Firefox
• Browser version: 140.12.0esr
• Device: various laptops

[notes] Error: Controller failed with OCP\Lock\ManuallyLockedException
	PUT /index.php/apps/notes/api/v1/notes/1044138?
	from 192.168.1.243 by historywalks at 13 giu 2026, 08:59:21

[webdav] Error: Exception thrown: Sabre\DAV\Exception\Locked
	PUT /remote.php/dav/files/historywalks/Notes/Early%20history/Refugees.md
	from 192.168.100.10 by historywalks at 12 giu 2026, 13:22:07

Start by reproducing the GNOME Files and browser workflow, then trace the notes API PUT and WebDAV lock messages shown in the issue. Identify where the editor-close lifecycle should release the lock; done means the local file becomes writable again after the browser windows close, without requiring the web interface.