fix: include max_file_size in S3 cache key to prevent stale digests

[Louiszk]

This PR fixes a caching bug where S3 cache keys did not account for max_file_size (see #568).

Previously, if a repository was requested with the default 50KB limit, and then requested again with a 100MB limit, the server would return the cached 50KB version because the cache key only relied on include/exclude patterns and the commit hash.

• Updated generate_s3_file_path in src/server/s3_utils.py to accept max_file_size and append it to the hashing string.
• Passed query.max_file_size into both calls to generate_s3_file_path inside src/server/query_processor.py.

While looking into this, I realized this strict hashing approach might cause unnecessary cache misses. For example, if a user requests a 500KB limit, and then a 2MB limit on a repo where the largest file is only 100KB, the current fix will treat them as different keys and trigger a re-clone.

Ideally, the cache would stay the same in this instance. In the future, it might be worth adding largest_file_encountered to the S3Metadata JSON and updating the lookup logic to allow compatible cache hits.

For now, adding the size to the hash key is a fast and reliable way to prevent the UI from serving incorrectly limited files.

[github-actions]

Hi there! We haven’t seen activity on this pull request for 45 days, so I’m marking it as stale.
If you’d like to keep it open, please leave a comment within 10 days. Thanks!

[Louiszk]

Hey, this was marked as stale, but it is still relevant.
@lcandy2 (or anyone from the team) could you take a look?
I also implemented dark mode in #569, which was marked stale as well.
Thanks!