Improve corrupt share permission situation - #64165

...rmissions
`SharedStorage::isValid()` returns false when the share source lost its
share permission, which makes every permission check return 0 while
reading keeps working. For the recipient that looks like arbitrary
breakage: uploads fail with 403, renames get reverted by the sync client,
and the file list still shows the folder as writable. Nothing was logged,
so there was no way to tell this apart from real corruption.
Log a warning once per storage instance naming the share, the owner and
the source file id plus its cached permissions, so the source that needs
repairing can be found.
Assisted-By: ClaudeCode:claude-opus-5
Signed-off-by: Marcel Klehr <mklehr@gmx.net>

When the source of a share lost its share permission in the file cache,
`SharedStorage::getPermissions()` returns 0 and every write is refused.
The shared cache never took part in that decision: it reported
`filecache.permissions & share.permissions`, so the file list showed the
folder and its contents as writable while every upload, move and rename
was answered with a 403. The web UI turns that into "Operation is blocked
by access control" and sync clients revert renames a few seconds later,
which makes a wrong permission value look like arbitrary corruption.
Mask the reported permissions down to read when the source is invalid, so
what the cache advertises is what the storage grants. Reading is left
untouched because it keeps working: `fopen()` in read mode bypasses the
permission checks.
The validity check moves into `SharedStorage::hasValidSourcePermissions()`
so the storage and its cache share one definition.
Assisted-by: ClaudeCode:claude-opus-5
Signed-off-by: Marcel Klehr <mklehr@gmx.net>

Assisted-by: ClaudeCode:claude-opus-5
Signed-off-by: Marcel Klehr <mklehr@gmx.net>