Shared library routes return 404 to personal access tokens and MCP tokens #8847

Summary

The shared library routes (/storage/library/:libraryId/*) answer 404 not_found to every request authenticated with a user bearer token (personal access tokens and MCP tokens), even for a team owner on a team with the shared library enabled. Only browser sessions, instance tokens and device tokens are accepted, so API and MCP clients cannot list, create or delete shared library entries. No existing caller uses a user token, so this is a gap rather than a regression.

Steps to reproduce

1. Create a personal access token for a team owner, on a team whose type has the shared-library feature.
2. POST /storage/library/<teamId>/some/entry with Authorization: Bearer <token> and body { "type": "flows", "meta": {}, "body": "[]" }.
3. The same 404 comes back for GET and DELETE.

Expected

The request is authorised like a browser session: team membership is loaded and needsPermission decides (including the read-only and team-scope checks that already exist for personal access tokens).

Actual

forge/routes/auth/index.js:134 gives user bearer tokens session.ownerType 'user' or 'user:expert-mcp', but the preHandler in forge/ee/routes/sharedLibrary/index.js:28 only loads the team membership when !request.session.ownerType. Both fall through to the 404 at the end of the hook.

References

• forge/ee/routes/sharedLibrary/index.js:12-37
• forge/routes/auth/index.js:114-134
• forge/routes/auth/permissions.js:210 already treats user and user:expert-mcp sessions like browser sessions for role checks.