Raise keydb size cap 64 MiB -> 128 MiB

The public UHD keydb (fvonline) is ~62 MiB and growing, leaving only ~2 MiB
under the old 64 MiB ceiling — updates would start failing as it grows.
128 MiB restores years of headroom while still bounding a decompression
bomb. Both cap sites (keydb.rs download/save, keydb_format.rs on-disk load)
bumped; the unrelated MKB cap in online.rs is untouched.

src/keydb.rs

@@ -41,9 +41,11 @@ use libfreemkv::{Error, KeySource};
 use crate::keydb_format::KeyDb;
 
 /// Upper bound on decompressed keydb size. The published keydb is a few MiB;
-/// 64 MiB is a generous ceiling that still caps a decompression bomb (a tiny
-/// zip/gz can otherwise inflate to GiB and OOM the daily refresh thread).
-const MAX_KEYDB_BYTES: u64 = 64 * 1024 * 1024;
+/// 128 MiB is a generous ceiling that still caps a decompression bomb (a tiny
+/// zip/gz can otherwise inflate to GiB and OOM the daily refresh thread). The
+/// public UHD keydb (fvonline) is ~62 MiB and growing, so 64 MiB was getting
+/// tight; 128 MiB leaves years of headroom.
+const MAX_KEYDB_BYTES: u64 = 128 * 1024 * 1024;
 
 /// Result of a KEYDB save/update -- path written, entry count, and byte size.
 #[derive(Debug)]

src/keydb_format.rs

@@ -23,9 +23,10 @@ use libfreemkv::aacs::types::{DeviceKey, HostCert};
 pub type NumberedUnitKey = (u32, [u8; 16]);
 
 /// Upper bound on the on-disk keydb.cfg size accepted by [`KeyDb::load`].
-/// The real public UHD keydb is a few MiB; 64 MiB is generous headroom while
-/// still bounding the worst-case allocation from a hostile/corrupt file.
-const MAX_KEYDB_BYTES: u64 = 64 * 1024 * 1024;
+/// The public UHD keydb (fvonline) is ~62 MiB and growing; 128 MiB is generous
+/// headroom while still bounding the worst-case allocation from a hostile or
+/// corrupt file.
+const MAX_KEYDB_BYTES: u64 = 128 * 1024 * 1024;
 
 /// Upper bound on parsed disc entries. The real public keydb carries
 /// ~170k+ entries, so the cap sits well above that while still bounding