Correct ri marshal compat: ri CLI/servlet only, not phantom downstreams

The previous wording named 'Ruby core docs build, rubygems-server, IDE
integrations' as marshal consumers. Verified against the codebase: the
actual readers are ri (lib/rdoc/ri/driver.rb) and ri --server
(lib/rdoc/ri/servlet.rb). RubyGems integration writes ri data on gem
install but doesn't read marshal back; IDEs that surface ri docs invoke
the ri binary, not the marshal format. The real risk is upgrade
compatibility against locally-cached .ri data, not external tool
breakage.

Author: claude

AGENTS.md

@@ -251,7 +251,7 @@ If you add an invariant to one of these paths — for example the `Context#add_m
 
 ### Marshal / ri Data Compatibility
 
-`RDoc::Constant`, `RDoc::ClassModule`, and other code objects implement `marshal_dump` / `marshal_load` to persist ri data on disk. Downstream consumers (the Ruby core docs build, rubygems-server, IDE integrations) read this format. Each class gates its dump shape with a `MARSHAL_VERSION` constant. Any change that alters the dumped array — adding/removing slots, reinterpreting an existing slot's meaning — needs the version bumped and the loader taught to handle both old and new data, or you break downstream consumers silently.
+`RDoc::Constant`, `RDoc::ClassModule`, and other code objects implement `marshal_dump` / `marshal_load` to persist ri data on disk, gated by a per-class `MARSHAL_VERSION` constant. The `ri` CLI (`lib/rdoc/ri/driver.rb`) and the `ri --server` servlet (`lib/rdoc/ri/servlet.rb`) read this format. Any change that alters the dumped array — adding/removing slots, reinterpreting an existing slot's meaning — needs `MARSHAL_VERSION` bumped and the loader taught to handle older payloads, otherwise locally-cached `.ri` data from an earlier rdoc version stops loading after an upgrade.
 
 ### Live Preview Server (`RDoc::Server`)