Strong agree on the boundary point, it matches what I keep running into: the components are individually solid, and the disagreements only show up once you actually chain them, which unit tests structurally can’t reach. Ironwood sharpens it, because a tool “supporting Ironwood” at its own surface isn’t the same as its outputs round-tripping cleanly through the next tool in the stack.
On which tests are most useful upstream: the highest-leverage one I’ve seen is an extension of the lightwalletd-vs-Go comparison you already run in CI, but at the artifact level rather than just RPC. Cross-implementation round-trip fixtures, pinned per version (“what tool A emits, tool B parses and validates”), turn a boundary break into a failing shared test instead of a support thread three weeks later. That class of failure is basically invisible until someone runs the whole route, which is your point exactly.