fix(deps): bump reva to fix restoring already-restored trash item returns 500

[mzner]

Description

RestoreRecycleItem returned a bare 500 CODE_INTERNAL when restoring a trash item whose trash entry no longer existed (e.g. it was already restored, or purged), instead of a 404 Not Found. This bumps the vendored reva dependency to pick up the fix (owncloud/reva#740), which maps the underlying ErrNotExist to errtypes.NotFound in RestoreRecycleItem, mirroring the existing handling in PurgeRecycleItem.

Related Issue

• Fixes OCISDEV-1370

Motivation and Context

A second restore request for the same trash key, such as a sync client re-submitting a request, produced a 500 that looked like a server error even though the original restore had already succeeded. This was observed in production, where a single bulk restore-from-trash burst produced ~138 benign 500s that masked the fact that the underlying restores had actually succeeded.

How Has This Been Tested?

• test environment: reva unit test suite (pkg/storage/utils/decomposedfs)
• test case 1: restore a trashed item once (succeeds), then restore the same key again -> now returns errtypes.NotFound instead of a bare *fs.PathError
• test case 2: go build ./... and go test ./pkg/storage/utils/decomposedfs/... pass in ocis after the reva bump

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.