OCM. Collaboration. Onlyoffice shows an error trying to open a remotely shared file when it's already locked

## Describe the bug
After receiving a remote share, there is no indication on the receiving end that the shared file is locked. If the file is already locked on the original server, opening the file with OnlyOffice on the receiving side will cause an error. Note that the error comes from OnlyOffice, and it's a generic "cannot open the file" type of error, so the user won't really know what's happening.

## Steps to reproduce
1. user1 in server1 shares a file with user2 in server2
2. user1 opens the file in server1 with Collabora
3. user2 in server2 doesn't see the file is locked (**the lock isn't visible in server2**)
4. user2 in server2 tries to open the file with OnlyOffice

## Expected behavior
Due to technical issues (we can't control OnlyOffice's behavior), I'm not sure if we can let user2 write the file somehow. That would imply letting user2 access to server1 and open the file with Collabora (which is the office app installed in server1). I don't think this is planned at the moment, and it seems a quite complex approach.

Alternatively, we could verify whether the file is locked in server2. Showing the lock icon for a locked file should be enough for the user to know he can't edit the file. It won't prevent the user from trying to open the file though.

## Actual behavior
An "editor couldn't be loaded" error message appears to the user.

## Setup
Default setup in both servers, with OCM enabled

```console
OCIS_XXX=somevalue
OCIS_YYY=somevalue
PROXY_XXX=somevalue
```

## Additional context
As far as I know, the behavior heavily depends on the office app installed on server2. As said, OnlyOffice shows an error, but Collabora switches to read-only mode instead.
OnlyOffice 8.1.3 and Collabora 24.04.5.1.1

Showing the icon in server2 might also have some additional problems:
* Lock state (and other info) might not be available when the page is loaded.
* Live state changes aren't expected. We'd need to connect to the sse endpoint of server1, but even if we do it server-side, it doesn't seem a solution that will scale because we don't know how many open connection we'll need to use.

We probably need to document this as a know issue if we don't find a good solution.