fix(store/fscache): Fragment cache filenames for long URLs

[bartventer]

• Introduce adaptive filename logic to split long base64-encoded URLs into directory fragments.
• Retain reversibility and compatibility with previous base64 filenames.

Closes #16

[bartventer]

Reviewed and approved.

[eric]

It seems like there still is a limit for how long a URL can be. Is that correct? Can that be tunable?

[bartventer]

@eric I ran some tests to check the current limits (see #18):

• Successfully tested URLs up to 100KB (139K char paths, 2844 directory levels) on Linux
• Performance scales reasonably: 50KB URLs take ~205ms per cache operation
• The 48-char fragment size works effectively on modern Unix filesystems

Most real-world URLs are under 2KB, so this should cover typical use cases on Linux/macOS.

However, Windows has stricter path limits (260 chars by default). Are you running on Windows? If so, could you share a repro? The fragment size might need platform-specific tuning for Windows compatibility.

[eric]

Sorry, I think I misread part of the implementation and thought there was some sort of a hard limit with the new implementation. Thank you for putting in that extra effort to confirm it performs well and doesn't have a practical limit!

[bartventer]

Sorry, I think I misread part of the implementation and thought there was some sort of a hard limit with the new implementation. Thank you for putting in that extra effort to confirm it performs well and doesn't have a practical limit!

No problem! Thanks for the question, it led to good testing and benchmarking that confirmed the implementation works well. Happy to clarify anytime.