Overall: strong foundations. A deterministic packer with parity tests against the live cache, a documented list of what the old packer lost, and a stock-diff gate on every build is the right base. My disagreements are about what "ours" really contains, about doing the cheap end-to-end test first, and about persisted data.
▎
▎ 1. The 3-way per-entry rebase
▎
▎ It's sound as a mechanism. My biggest concern is the base. Using base = stock 231 assumes the hand-edited leak started from stock 231. Your own examples show it didn't: the 4 scripts were backports, 2628 was an older Jagex copy, and spellbook 218 was an older Jagex layout. So a good part of "KEEP 6724" is probably stale Jagex data from older revisions, not your edits. KEEP would carry it forward over newer data.
▎ - Before trusting KEEP, check its provenance systematically: hash each KEEP entry against stock caches from earlier revisions (OpenRS2 has them). Anything identical to some stock revision is stale Jagex, not custom, so TAKE it. You've done this by hand for a few; do it for all 6,724.
▎ - Field-level MERGE is risky where fields depend on each other: model ids with recolour/retexture arrays, ops with params, inventory and equipment fields. Treat those entries as atomic, or validate the merged entry as a whole.
▎ - Interfaces need group-level checks, not just per-component ones. On our 231 server, an interface with gaps in its component ids crashes the client when it opens (it walks every id and reads each). Dropping or merging components can create gaps or shift ids. Check after the merge that every group is contiguous, parents are valid, and every cs2 or server reference by packed id still points at the right component.
▎ - Add a reference-integrity pass across types after the merge: items to models and sequences, npcs to models and anims, interfaces to scripts, scripts to enums, structs and params. A kept entry can point at something Jagex repurposed. Params, enums and structs being reused with a new meaning is the classic silent breakage.
▎ - The rev-gated layer is fine for the transition. Collapse it after cutover rather than keeping 231 and 241 buildable for good: double maintenance grows quietly.
▎
▎ 2. Client and protocol first? Yes, do it first.
▎
▎ A walking skeleton costs a day or two:
▎ 1. Stock 241 cache, the 241 injected client and RSProt's 241 module, logging in to a minimal server and walking.
▎ 2. Then your 241 cache on the same setup.
▎
▎ It surfaces the unknowns that could kill the plan before the expensive cache work is done:
▎ - the injected client and RuneLite fork for 241
▎ - the login block
▎ - js5 index count and the CRC check
▎ - 117 HD support for 241
▎
▎ Right now P3 and P4 are assumed cheap, and you'd find out last.
▎
▎ 3. Remapping ~1000 colliding ids
▎
▎ Right call, with three cautions:
▎ - Check the encodings before choosing ranges. 70000+ for objects exceeds 16 bits. Confirm every place a loc id travels can carry it: zone packets (loc add/change/del), map loc decoding, anything server-side stored as a short. The same check goes for every remapped type. Leave headroom above Jagex's future growth, not just today's maximum.
▎ - Persisted data is the easy one to miss. Player saves, banks, GE or trading post offers in the database, drop tables, shops, spawn files, the website (store and prices), logs, Discord bots, and plugin price feeds that key by item id. Keep one old-to-new mapping file as the single source of truth, and drive both the cache rewrite and a one-off save migration from it. Run that migration against a copy of live saves before release.
▎ - Keep a remap registry permanently, so future upgrades start from known custom ranges.
▎
▎ 4. Commonly missed in revision upgrades
▎
▎ - Varps and varbits that moved or changed meaning, and server code with hard-coded ids.
▎ - Interface component ids that shifted inside Jagex interfaces your server drives: hard-coded in server code, and in if_ events and client script calls.
▎ - Client script signatures: arguments added or reordered, so every server runClientScript call with an argument list needs checking.
▎ - Enums, structs, params and db tables (dbrow/dbtable) repurposed; modern interfaces lean on db tables.
▎ - Cache index count: new indexes break a login CRC check written for a fixed range.
▎ - Format changes: sequences and skeletal animations, model encodings, sounds, sprites, fonts. Also client features your server must at least tolerate (world-entity and active-world packets).
▎ - XTEAs: 241 doesn't need them for locs, but any region you import from older caches does, and your tool must handle mixed sources.
▎ - 117 HD: its texture, model and area overrides are keyed by ids, so it needs a 241-aware version, and your custom models and areas re-checked.
▎ - RuneLite plugins that use widget, component or varbit ids (the gameval constants) or obfuscated hooks break quietly.
▎ - Rollback: keep the 231 build, cache, client and save snapshot deployable until 241 has run for a while.
▎
▎ 5. Is 241 worth it?
▎
▎ Only if you need engine changes, not just assets. Before committing, try the cheaper alternative: backport the content you want (Raids 4's models, animations, maps, objects, NPCs and interfaces) from the 241 cache into 231, with your existing remap tooling. That's far smaller than a full rebase.
▎
▎ It fails if that content depends on client features 231 lacks:
▎ - new cs2 opcodes
▎ - model or animation formats
▎ - newer interface mechanics
▎
▎ So spike it: pull one Raids 4 room into 231 and see if it renders and its interfaces work. If it does, backporting wins for now. If it doesn't, 241 is the price of that content, and the plan above is a good way to pay it.

The cold-cache agent is still running for our own browser client; I'll report when it's done.