atproto-store had drifted to rocksdb-native 3.17.1 + hypercore-storage 3.1.2 while favela-web, atproto-did-peer and favela-community all ran 3.17.2 / 3.2.0. Nobody declares rocksdb-native directly — it arrives via corestore -> hypercore-storage, all on caret ranges, so the versions were pure install-date drift rather than a decision. Pinned via `overrides` rather than a direct dependency: this package does not import rocksdb, so declaring it as a dep would be a lie, and an override is explicit, reviewable and survives reinstall. TARGET IS 3.17.2, NOT LATEST. npm latest is 3.17.3; converging there would have left the other three siblings behind and simply moved the split. Aligning means converging on what is deployed and proven. Effect on the mobile bundle (org #36 spike 1), measured: before 42 addons, 3 rocksdb copies, 41.7 MB android-arm64 after 41 addons, 2 rocksdb copies, 30.2 MB (-11.5 MB) Same drift also produced this session's `pgh publish` conflicts, so this removes a real source of those too. ⚠ THE REMAINING rocksdb 3.15.0 IS NOT TOUCHED, DELIBERATELY. It comes from hyper-rooms (via favela-community), pinned by hypercore 11.28.1 -> hypercore-storage ^2.8.0. Moving it means crossing the hypercore-storage 2.x->3.x MAJOR on a library that pear-git-v3 symlinks and uses for live orgs/issues data, and DEPENDENCY-STANDARD.md §3 explicitly defers that pending a migration test. Not a drive-by change. Verified: the atproto-repo symlink survived the install; atproto-store 80/80, favela-web node+bare suites, atproto-did-peer 9/9 all green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>