Big file 150 mb not working fix please si

[fire-bot]

Sent by Lakhwinder Singh (lakhwindersingh95001@gmail.com). Created by fire.

---

[yhs0602]

A first pass for this is now in PR #728.\n\nThe maintenance branch now avoids keeping large file byte arrays in the in-memory ProjectDataStorage cache, so opening a very large file does not leave the full content pinned in the cache map after the first read. This should reduce memory pressure for cases like 150MB inputs.\n\nThere is still more work to do for fully streaming large-file handling, but this changes the baseline in the right direction.

[yhs0602]

Another large-file mitigation is now on the maintenance baseline branch: expanded archive/dex cache keys are computed with a streaming SHA-256 digest instead of reading the entire source file into memory first. This removes one up-front OOM risk before extraction/disassembly starts, on top of the earlier binder payload, string result, and detail preview reductions in #728.

[yhs0602]

Hex rendering is also bounded now on the maintenance baseline branch: the Hex tab shows a capped preview for very large files instead of pushing the entire byte array through Compose at once, and it surfaces a notice with the original size. This is another UI-side mitigation for the large-file cluster tracked in #523.

[yhs0602]

Text rendering is now bounded on the maintenance baseline branch as well: the Text tab only decodes/highlights a capped preview for very large files and surfaces the original size in the UI, instead of pushing the full text payload through the syntax highlighter at once. This extends the large-file mitigations beyond string search, details, cache hashing, and hex rendering.

[yhs0602]

Another large-file reduction is now on the maintenance baseline branch: Hex, Text, and Analysis previews no longer call the full-file read path just to build capped previews. They now read only the bounded preview/sample bytes needed for those tabs, so opening a very large file no longer requires loading the entire source into memory for those views first.

[yhs0602]

Opened #741 as the first large-file stability follow-up. This slice adds failing tests first, then bounds string-search rendering payloads and analyzer-emitted string matches so large printable regions stop allocating very large UI strings. This is a partial mitigation, not the full large-file cleanup yet.