[RUM] Reo.dev intent pixel: 90% of event POSTs rejected 400 for 30+ days, on 66% of sessions

## Summary

The embedded **Reo.dev intent pixel** rejects roughly **90% of the events it posts**, and has done so for at least 30 days. In the last 24h: **1,105 × `POST https://aplo-evnt.com/api/v1/intent_pixel/track_request` returned HTTP 400**, against only 116 × 200 on the same host — a **90.6% failure rate** — touching **102 of 154 sessions (66%)**.

Nothing in Studio's error stream shows this, which is why it has gone unreported: `shouldKeepEvent` deliberately drops errors originating in the Reo bundle (`THIRD_PARTY_SCRIPT_FRAME`), and a 4xx *resource* response never produces a JS error in the first place. The only place it is visible is the RUM resource stream.

Surfaced by the automated daily RUM review (app `f590deee-…`).

## Datadog findings

**`@type:resource @resource.url_host:aplo-evnt.com`**

| Window | 400 | 200 | % 400 | Sessions w/ 400s | Total sessions |
| --- | --- | --- | --- | --- | --- |
| 24h → now | **1105–1118** | 116 | **90.6%** | 102 | 154 |
| 48h → 24h ago | 934 | 104 | 89.7% | 87 | 127 |
| 7d → 48h ago | 2587 | 324 | 84.9% | 321 | 521 |
| 14d → 7d ago | 6643 | 558 | 90.8% | — | — |
| 30d → 14d ago | 885 | 102 | 87.6% | — | — |

- **Endpoint:** a single one — `POST /api/v1/intent_pixel/track_request`, `@resource.type:fetch`.
- **Not new, and not a spike.** The failure *ratio* has sat at 85–91% across every window back to 30 days. This is a steady-state condition, not a regression.
- **Server-side rejection, not a blocked request.** Mean response time **188ms** with a real 400 status. An ad-blocked or firewalled beacon would surface as a network error, not as an HTTP 400 — something is answering and refusing the payload.
- **Reach is broad, not concentrated:** ~2/3 of all sessions in every window (66%, 69%, 62%), so this is not one bad client or one bad browser.

## Why this is worth fixing

Two costs, neither of them user-visible — which is exactly why it needs filing rather than watching:

1. **The analytics data is largely not landing.** If ~90% of intent-pixel events are refused, any funnel or intent reporting built on Reo is being drawn from roughly a tenth of the traffic. Whatever decisions rest on that data are resting on a biased sample of unknown shape.
2. **~1,100 pointless POSTs/day run in customers' browsers**, each ~188ms, on two thirds of sessions.

## Where it comes from

Studio's own involvement is three lines — [`src/integrations/reo/reo.ts`](src/integrations/reo/reo.ts) loads the vendor bundle and hands it a client ID:

```ts
loadReoScript({ clientID: import.meta.env.VITE_REO_DEV_CLIENT_ID })
.then((Reo) => {
Reo?.init?.({ clientID: import.meta.env.VITE_REO_DEV_CLIENT_ID });
return reoClient = Reo;
});
```

The failing request is issued from inside the vendor's bundle, so RUM cannot see the request body and we cannot see which field it dislikes. Note `aplo-evnt.com` is Reo's event host — distinct from `api.reo.dev`, which separately returned 5 × 400 in the same window.

**We are already on the latest release.** `reodotdev` is pinned `^1.0.0` and resolves to **1.1.0**, which is the newest version published (`1.0.0`, `1.0.1`, `1.1.0`). So there is no upgrade to take.

## Suggested next steps

1. Reproduce locally with a valid `VITE_REO_DEV_CLIENT_ID` and read the 400's **response body** in devtools — that is the one piece of information RUM structurally cannot provide, and it likely names the rejected field.
2. Confirm the production `VITE_REO_DEV_CLIENT_ID` is the right ID for the current Reo account/plan. A stale or wrong-environment client ID rejected at the ingest boundary would produce exactly this shape: uniform, fast, near-total 400s.
3. If the ID is correct, this is a vendor-side ingest bug — worth raising with Reo support, with the endpoint and ratio above.
4. If Reo is not actively used, consider dropping the integration; it is currently pure cost.

## Notes / limitations

- No customer identifiers, emails, hostnames, org or instance IDs are included here.
- RUM cannot see request or response bodies, so the *reason* for the 400 is not directly observable — hence step 1 above rather than a root cause.

Start in src/integrations/reo/reo.ts and reproduce locally with a valid VITE_REO_DEV_CLIENT_ID. Inspect the 400 response body, then verify that the production client ID matches the current Reo account or plan. Done means identifying whether Studio can correct the integration or whether the evidence must be raised with Reo support.

Written by the indexing model from the issue text.