fix(CrawlService): Validate actual response body size in archiveFile

[Huge]

Problem

When archiving non-HTML bookmark content in CrawlService::archiveFile(), the service checked the Content-Length header against MAX_BODY_LENGTH (90 MB):

$contentLengthHeader = $resp->getHeader('Content-Length');
$contentLength = $contentLengthHeader !== '' ? (int)$contentLengthHeader : 0;

if ($contentLength < self::MAX_BODY_LENGTH) {
    ...
    $file->putContent($resp->getBody());
}

If a remote server returns chunked transfer-encoding (omitting the Content-Length header entirely) or provides a falsified low header value (e.g., Content-Length: 10), $contentLength evaluated to 0 or a small integer. As a result, the condition evaluated to true, and the entire unbounded response body could be written to user storage.

Solution

1. Check Content-Length early; return immediately if reported as >= MAX_BODY_LENGTH.
2. Inspect the actual response body size (strlen($body)) before creating a file and writing it to user storage.
3. Skip archiving payloads whose actual byte size reaches or exceeds MAX_BODY_LENGTH.

Tests

• Added unit tests in tests/CrawlServiceTest.php:
  • testArchiveFileRejectsMissingContentLengthWhenBodyOversized: verifies that chunked responses with missing Content-Length exceeding MAX_BODY_LENGTH are not saved.
  • testArchiveFileRejectsSpoofedContentLengthWhenBodyOversized: verifies that responses with a spoofed small Content-Length exceeding MAX_BODY_LENGTH are not saved.
  • testArchiveFileSavesValidBodyWithinLimit: verifies that legitimate files within the limit continue to be archived correctly.
• All unit tests pass cleanly (202 passed, 18 skipped circles).
• Code style check (composer cs:check) passes without issues.