One caveat with that trick: if the server picked a different file or the link now points at a new version, Firefox will happily splice the old .part onto the new bytes and you get a corrupt file with no error. Resume requests only check the range, so unless the server returns an ETag or Last-Modified that matches, nothing guarantees the two halves belong together. Worth checking a hash afterwards if the source publishes one.
Do you periodically re-read the old discs to check them? I burn a par2 recovery set (around 10 percent) onto each disc alongside the data, and once a year run a full verify with dvdisaster or just par2 verify. A disc that starts throwing correctable errors gets re-burned while it can still be read cleanly, which matters more to me than the rated lifetime of any single disc.
OsmAnd's map engine is mostly native C++. The hardened allocator wraps malloc for that native heap, where decoded tile geometry and texture buffers live during scroll. The Java side still uses ART's GC, so you get a split: the UI can feel fine while the native render path pays the hardened-allocator tax on every tile churn. That also matches why a Leaflet WebView (one heap model) can feel different from the same map data inside OsmAnd.