Shared library delete removes entries it should not: empty path wipes the library and "_" and "%" act as wildcards #8848

Summary

DELETE /storage/library/:libraryId/* treats any path that is not an exact entry name as a folder and deletes every row whose name matches <path>/% with a SQL LIKE. The path is not escaped, so two separate problems lose data.

Steps to reproduce

1. Create entries a/b/c, a/b/d, a_b/x and aXb/x in a team library.
2. DELETE /storage/library/<teamId>/a_b. All four entries are deleted (deleteCount: 4), because _ matches any single character, including / and X.
3. The same happens with %: deleting folder 100% (sent as 100%25) also deletes 100abc/p.
4. Create two entries, then DELETE /storage/library/<teamId>/ with an empty path. The response is { status: "okay", deleteCount: 2 }: the whole library is gone.

Expected

Only entries under the exact folder are deleted, whatever characters its name contains. An empty path is rejected (400) rather than meaning "everything".

Actual

See the steps. GET on a folder has the same wildcard problem, so listing a_b also shows entries from a/b and aXb, and the name check on create (byPath(..., name + '/')) rejects valid names: with a/b/c stored, creating an entry named a_b returns 400 invalid_name. On Postgres, where \ is the default LIKE escape character, a folder whose name contains a backslash cannot be deleted at all.

References

• forge/ee/db/models/StorageSharedLibrary.js:51-59 (byPath builds Op.like with ${name}% and no escaping)
• forge/ee/routes/sharedLibrary/index.js:150-181 (delete route), :131 (GET), :88 (create)
• Escaping needs an explicit ESCAPE clause, since Op.like adds none and sqlite has no default escape character, or a literal prefix match instead of LIKE. The empty path should be rejected in the delete route.