fix(files_trashbin): normalize paths before restoring and deleting

[joshtrichards]

• Resolves: [Bug]: Node is not deleted from trashbin table upon permanent deletion. #49430

Summary

Fix leading-slash handling when LegacyTrashBackend passes trash item paths to Trashbin::restore() and Trashbin::delete() APIs.

ITrashItem::getTrashPath() currently returns paths with a leading slash, for example:

/file.txt.d1731917455

The Trashbin APIs expect paths relative to files_trashbin/files/. Passing the slash-prefixed value can produce paths such as:

/files_trashbin/files//file.txt.d1731917455

Filesystem path normalization currently masks the extra slash, but for permanent deletion the leading slash also causes the files_trash database cleanup query to use /file.txt instead of the stored ID file.txt. As a result, the physical trash item is deleted but its metadata row remains.

This change normalizes the path at the LegacyTrashBackend boundary before calling Trashbin::restore() and Trashbin::delete(), keeping those callers consistent with the APIs' relative-path contract.

Changes:

• Clarify the relative-path contracts in the Trashbin::restore() and Trashbin::delete() docblocks.The delete() documentation was already relatively clear; restore() required the more substantial clarification.
• Normalize trash paths in:
  • LegacyTrashBackend::restoreItem()
  • LegacyTrashBackend::removeItem()
• Add regression coverage for:
  • permanent deletion through the trash manager;
  • removal of the corresponding files_trash row;
  • canonical delete hook paths;
  • restore behavior through the trash manager;
  • canonical restore hook paths.

The existing ITrashItem path representation is unchanged to avoid affecting other consumers that rely on its leading slash.

Follow-up ideas

• Existing orphaned files_trash rows are not repaired by this change, but they are already orphaned today. This fix prevents new incorrect rows from being left behind. Historical metadata cleanup can be addressed separately in a follow-up repair PR.
• Audit files_versions for anything possibly similar (not necessary applicable - just came to mind)

TODO

• Audit the Team Folders ITrashBackend implementation for similar issues (though any changes will obviously be handled in a separate PR)
• Consider backporting

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI