Shared library create accepts empty and trailing-slash entry names, and a non-JSON flows body that breaks reading it back #8853

Summary

POST /storage/library/:libraryId/* validates only that type is present. Some inputs are accepted and then cause broken data or a 500 later.

Steps to reproduce

1. As a team member, POST /storage/library/<teamId>/ (empty name) with { "type": "functions", "body": "x" }. It returns 201, and GET /storage/library/<teamId>/ now returns x instead of the folder listing.
2. POST /storage/library/<teamId>/tr/ with the same payload. It returns 201 and stores an entry named tr/.
3. POST /storage/library/<teamId>/bad with { "type": "flows", "body": "not json" }. It returns 201. GET .../bad?type=flows then returns 500 Unexpected token 'o', "not json" is not valid JSON.
4. POST .../a%2F..%2Fb stores an entry named a/../b. Plain .. and . segments are normalised away by the router, but encoded slashes are decoded after that.
5. POST with no body and no content type returns 500 Cannot read properties of undefined (reading 'type'), and a JSON body of null returns the same 500 for null, instead of the 400 for a missing type.

Expected

1. Names that are empty, end with /, or contain empty, . or .. segments are rejected with 400 invalid_name.
2. A flows entry whose body is not valid JSON is rejected with 400 at create time.
3. A missing or null body returns 400 invalid_request.

Reference

forge/ee/routes/sharedLibrary/index.js:46 reads request.body.type with no body guard. :47-49 takes the wildcard name unvalidated. :56 only stringifies object bodies. :120 parses direct.body for type flows with no error handling.