docs: drop a source name from the two keydb size-cap comments

Both MAX_KEYDB_BYTES comments justified the 128 MiB ceiling by naming
the public keydb they were sized against. The number and the reasoning
are the useful part; the name is not, and it trips the pre-commit
scan. Keep the justification, drop the name.

src/keydb.rs

@@ -43,8 +43,8 @@ use crate::keydb_format::KeyDb;
 /// Upper bound on decompressed keydb size. The published keydb is a few MiB;
 /// 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.
+/// public UHD keydb 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.

src/keydb_format.rs

@@ -23,7 +23,7 @@ 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 public UHD keydb (fvonline) is ~62 MiB and growing; 128 MiB is generous
+/// The public UHD keydb 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;