fix(codeapi): answer 404 on delete of an absent object without ownership record

[Shabonasar]

Summary

sessionAuth answers 403 to DELETE /files/:session_id/:fileId whenever ownership cannot be established. For sessions that predate the durable session-owner:* record (reason unknown) this can never succeed, so a client sweeping its retention window keeps retrying the same DELETE for an object the bucket has long since dropped.

With this change a DELETE that fails authorization first asks the file-server for the object's metadata. If the object is absent, the route answers 404, which is what deleteSessionObject already returns for an absent object once authorized, and what LibreChat's deleteCodeEnvFile treats as "already gone". If the object still exists, the response stays 403.

Downloads and metadata reads are untouched: the check runs only for DELETE and only after ownership was denied.

Observed

After upgrading a deployment whose sessions were created before session-owner existed, LibreChat logged Error deleting file Request failed with status code 403 on every retention sweep (100 per pass) while codeapi logged Unauthorized delete: Cached session key: null | ... | Reason: unknown. The objects had already been removed by the bucket lifecycle. rehydrate-session-cache restores such sessions, but it needs a manifest and a manual run, while the records keep going into backoff until then.

Test plan

• api image builds with the change
• Deployed against LibreChat v0.8.8-rc3: DELETE of a non-existent object without ownership record answers 404
• DELETE of an existing object by another user still answers 403; DELETE by the owner answers 200