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

`@cloudfour/hbs-helpers` is on npm at `0.12.0` and declares:

```json
"main": "./index.js",
"files": ["index.js", "CHANGELOG.md", "lib"]
```

with no `exports` field.

## Why it's worth doing

`exports` defines the package's public interface. Right now the `files` allowlist publishes `lib/`, so every helper module in there is individually importable and those paths are de facto API — we can't reorganise `lib/` without potentially breaking someone. An `exports` field makes the entry point explicit and blocks deep imports.

That matters a bit more here than in most of our packages, because a helpers library is exactly the kind of thing people are tempted to cherry-pick a single module from.

## Why it isn't urgent

It's a breaking change. Anyone currently deep-importing gets `ERR_PACKAGE_PATH_NOT_EXPORTED`, with no deprecation path. This should ride along with the next major.

Worth deciding at the same time whether individual helpers *should* be importable — if so, `exports` can declare subpaths deliberately rather than leaving the whole directory open:

```json
"exports": {
".": "./index.js",
"./lib/*": "./lib/*.js"
}
```

Inspect the package manifest for @cloudfour/hbs-helpers and compare its current main and files declarations with the proposed exports examples. Decide whether individual helpers should remain importable as deliberate subpaths, then add the chosen exports policy for the next major and verify that the published entry points match that decision.

Written by the indexing model from the issue text.