Bring-your-own decision engine — first-class support

## Summary

The plugin is excellent at *deciding* experiences itself (random-split experiments, audience/campaign resolution) and rendering them. A growing use case is the opposite: a customer already owns a **decision engine** — an in-house personalization/experimentation service, or a third party — and wants the plugin to **apply** its decisions, while the engine keeps ownership of segmentation, bucketing, and exposure tracking.

This is the tracking epic for making that "bring your own engine" (BYO) path first-class. It comes out of a real integration where the **audience seam carried it** — every engine decision modeled as an async audience resolved through an auth-proxy worker — which worked, but surfaced the gaps tracked below.

## Integration shape

```
browser ──► aem-experimentation (client)
│ resolves "remote" audiences / assignments
▼
edge worker (auth proxy) ──► customer decision engine
- hides the API key
- reads the visitor id (cookie)
- normalizes the decision
```

## Already landed

- #63 — a single audience/campaign per selector no longer crashes the manifest parsers (the common BYO shape: one remote decision per slot).
- #65 — multi-word audience/campaign names now resolve at page level (they were camelCased lossily before).

## Enablers

Each is an individually shippable PR:

- [ ] #67 — `resolveAudiences`: batched, context-aware audience resolution (+ client helper)
- [ ] #68 — `getAssignment`: external experiment assignment (don't randomize)
- [ ] #69 — `rumTracking`: exposure/tracking override
- [ ] #70 — `renderDecision`: pluggable decision renderer
- [ ] #71 — versioned client ⇄ engine decision contract (+ contract tests)
- [ ] #72 — reference auth-proxy worker (`examples/`)

## Direction / decisions

- **Converge on one decision provider.** Audiences, campaigns, and experiments should resolve behind a single provider abstraction rather than three parallel mechanisms. The enablers above are the seams that provider composes; it's also where metadata-name normalization folds together cleanly for all three.
- **Reference material lives in this repo under `examples/`** (for now).
- Every new hook is **opt-in and a no-op by default** — no behavior change for projects that let the plugin do the deciding.

## Non-goals

- Bundling any specific engine or vendor.
- Changing default behavior for existing projects.

Start by reading the enabler issues #67–#72 and the existing audience-resolution path described in this issue. Check the client, auth-proxy integration, and examples/ reference material to understand how one provider should compose the hooks. Done means the listed BYO-engine enablers are implemented as opt-in no-ops by default, with the decision contract and contract tests in place.

Written by the indexing model from the issue text.