[TASK] Detect type-level breaking changes (all published packages)

### Description

I'm filing this as a quick followup to a comment in #345. We should plan on doing this _before_ releasing any package as 1.0.0. This will be valuable:

- As a safeguard, to help catch unexpected semver-major changes (runtime and types alike)
- To have confidence about API stability, and any claims we make about it

---

### Checklist

- **Does it need UI/UX design?** No.
- **Does it need API design?** It _is_ (meta-)API design.
- **Does it need design around state flow?** Not in the sense this question was intended 🙃
- [x] **Does it need a test plan?**
- The value of this will come from integrating it in CI

I'm... not sure I'm using this checklist right?

---

### Design

- **Technical Design Doc Links**: [TODO]

---

### Dependencies

- Motivation/priority
- Time/bandwidth

---

### Additional Notes

- I'd probably start by looking at [Semantic Versioning for TypeScript Types — Appendix B: Tooling](https://www.semver-ts.org/appendices/b-tooling.html) in more detail

---

### Related Issues

- #296 (relates as discussed in #345)

Start by reading the discussion in #345 and related issue #296, then review Semantic Versioning for TypeScript Types — Appendix B: Tooling. Define how type-level breaking changes should be detected across all published packages and integrated into CI before any package reaches 1.0.0.

Written by the indexing model from the issue text.