Adopt an `exports` field in the next major

`@cloudfour/eslint-config` v26.1 turns `package-json/prefer-exports` off, because adding an `exports` field is a breaking change for consumers and shouldn't surface as a lint error on every repo. That decision is in cloudfour/eslint-config#710.

It's still worth doing on packages that are genuinely published, though, so this is the follow-up issue for this one.

## Where we are

This package is on npm at `2.0.2` and declares:

```json
"main": "./src/index.js"
```

with no `exports` field.

## Why it's worth doing

`exports` defines the package's public interface. With only `main`, anything under `src/` is importable, so consumers can reach into internals and those paths become de facto API — we can't move or rename a file without potentially breaking someone. An `exports` field makes the entry point explicit and blocks deep imports.

## Why it isn't urgent

It's a breaking change. Anyone currently deep-importing gets `ERR_PACKAGE_PATH_NOT_EXPORTED`, and there's no deprecation path — it works or it doesn't. This should ride along with the next major rather than going out on its own.

Roughly:

```diff
- "main": "./src/index.js",
+ "exports": "./src/index.js",
```

Worth checking the README examples still describe importable paths afterwards, and that the `files` allowlist still covers whatever `exports` points at.

Start with the package manifest that currently declares main as ./src/index.js and inspect the README examples and files allowlist. Verify that the public entry point is represented by exports, that the allowlist covers it, and that the documented import paths remain accurate for the next major release.

Written by the indexing model from the issue text.