Large bundle size (already!)

This is something I’ve intentionally deferred because it intersects with tooling which has already eaten up a lot of time and energy. But it should be tracked, and some initial observations are worth dropping here for a starting point.

- The `crypto-js` library is quite large, and probably not the ideal solution for `digest` anyway. Any solution should likely also be optional, as it is in ORXE. I’ve looked at other options, but that’s best for another issue.
- The `Temporal` polyfill is gargantuan. It’s also poorly set up for bundle size optimization like tree shaking (this can be improved by importing the parts in use directly from source, but it’s worth reconsidering the polyfill in general depending on the standard’s progress)
- The `web-tree-sitter` WASM size is large-ish, and `tree-sitter-xpath` isn’t tiny either. These would benefit from aggressive caching.
- In general the best tooling-side approach to bundle size optimization is an open question. Besides deferring for pragmatic progress reasons, it also makes sense to hold until other stories are more clear (like offline, PWA if we pursue that, etc)

No files, tests, or entry points are named. Start by identifying the current bundle tooling and measuring the contributions from crypto-js, the Temporal polyfill, and web-tree-sitter; completion is not defined until the optimization scope and target are agreed.

Written by the indexing model from the issue text.