Backend [avatar]: Content-Length header is violently stripped when avatar file size is zero

Bug Description

When Rocket.Chat serves avatar image files, it determines the file's HTTP headers based on internal metadata. However, an incorrect truthy check on the file's size results in the Content-Length header being stripped completely if the file size evaluates to 0 bytes.

Steps to Reproduce

1. The server receives a request for an avatar.
2. The avatar utility identifies a corresponding file reference, but it happens to have a size of 0 bytes (e.g., an empty file due to sync issues, intentional placeholder overrides, or zero-byte cache objects).
3. The server executes apps/meteor/server/routes/avatar/utils.ts around line 43:

if (file.size) { // 0 evaluates to false
	res.setHeader('Content-Length', file.size);
}

4. Because 0 is falsy in Javascript, the Content-Length header is entirely omitted from the HTTP response.

Expected: The system should recognize 0 as a valid file size and explicitly set Content-Length: 0 on the HTTP response, which is crucial for proxy servers, CDNs, and client apps to properly terminate the reading stream.
Actual: The header is omitted, leading to potentially hanging requests or invalid HTTP spec adherence.

Environment

• Rocket.Chat version: Develop branch (latest)

Possible Fix

Explicitly verify that size is a defined number instead of relying on weak truthy evaluation:

if (typeof file.size === 'number') {
	res.setHeader('Content-Length', file.size);
}

Additional Context

I discovered this via static code analysis while hunting for weak Javascript truthiness checks across the backend. Missing a Content-Length for a 0 payload violates strict HTTP implementations. I am preparing a simple PR to strengthen this type check.

Start in apps/meteor/server/routes/avatar/utils.ts around line 43, where the avatar response sets the Content-Length header from file.size. Verify the zero-byte case and ensure the completed behavior preserves Content-Length: 0 when the file size is zero.