[RUM] Monaco DI "UNKNOWN service" errors survive the #1592 fix — 75% of errors on v2.159.2, now that the #1609 deploy gap is closed

## Summary

Production has finally moved off v2.156.4 — it now serves **v2.159.2** (`prod_fdc1142`), which closes the 12-day delivery gap in #1609. That release **contains** the #1592 fix (commit `14865449`, first tagged v2.156.5, an ancestor of the deployed commit).

The Monaco DI errors are still happening anyway:

```
[createInstance] um depends on UNKNOWN service actionWidgetService.
[createInstance] Fm depends on UNKNOWN service ICodeLensCache.
[createInstance] tb depends on UNKNOWN service IInlayHintsCache.
[createInstance] Lk depends on UNKNOWN service ISuggestMemories.
[createInstance] _x depends on UNKNOWN service treeViewsDndService.
```

So #1609's premise ("the fix never shipped") no longer explains it, and #1592's fix — removing the eager Monaco import — was **not sufficient**. Filing separately rather than reopening #1592, because the cause is a different one: the fix did what it claimed, and the errors survive it.

## Datadog findings (last 24h, `env:prod`, version `prod_fdc1142` only)

| | |
| --- | --- |
| Events | **275** unhandled `source` errors (55 / 55 / 53 / 52 / 52 across the five services) |
| Sessions | **20 of 127** on this release (16%) |
| Handling | `unhandled` |
| Share of all errors on this release | 267 of 356 (**75%**) |

Per-session rate has not improved — it is slightly worse than when #1592 was filed (13 of 166 sessions, 7.8%, vs 20 of 127, 15.7%; different traffic mix, so treat as "unchanged at best", not a regression).

Views affected (every surface that opens an editor):

| errors | view |
| --- | --- |
| 85 | `/$organizationId/$clusterId/config/` |
| 60 | `/$organizationId/$clusterId/instance/$instanceId/databases/$databaseName/$tableName/` |
| 45 | `/$organizationId/$clusterId/instance/$instanceId/config/` |
| 25 | `/$organizationId/$clusterId/apps/` |
| 20 | `/$organizationId/$clusterId/logs/` |
| 20 | `/$organizationId/$clusterId/instance/$instanceId/logs/` |
| 20 | `/$organizationId/$clusterId/databases/$databaseName/$tableName/` |

Stacks land in `toggleHighContrast-el2uNoWb.js` → `editor.api-OBQnf1nL.js`, entered from `onMouseMove` → `suggestHoverAnchor`, i.e. hovering in the editor.

## Verified against the bundle production actually serves

No RUM attribute involved — `curl https://fabric.harper.fast/` and follow the chunks:

- Entry chunk `assets/index-BLswmOju.js` initializes RUM with ``version:`prod_fdc1142` ``.
- **The eager path is genuinely fixed.** `editor.api-OBQnf1nL.js` no longer appears as a static import of the entry — its only occurrences there are inside a dynamic-import preload manifest array. `index.html`'s `modulepreload` list contains no Monaco chunk (`tokenization-uOBOyHAS.js` is 8.5 KB and contains none of the five service ids). #1592's specific defect is gone.
- **The chunk split it blamed is still there:**
- `assets/editor.api-OBQnf1nL.js` (2.6 MB) — contains `getSingletonServiceDescriptors` and the `UNKNOWN service` throw. Monaco core + the standalone service collection.
- `assets/toggleHighContrast-el2uNoWb.js` (1.15 MB) — contains all five of `actionWidgetService`, `ICodeLensCache`, `IInlayHintsCache`, `ISuggestMemories`, `treeViewsDndService`. This is the `monaco-editor/features/register.all` chunk.
- `toggleHighContrast` **imports from** `editor.api`, so ES module semantics guarantee `editor.api` evaluates *first* — before those five `registerSingleton` calls run. Making everything lazy doesn't change that ordering; it just moves both chunks later.

That is why removing the eager import didn't help: eagerness was never the load-bearing part. The ordering between the two chunks is.

## Where to look next

`src/lib/monaco/setup.ts` imports `monaco-editor/editor` (→ `editor.api`) on the line above `import 'monaco-editor/features/register.all'`, so even inside the lazy graph core evaluates before the registrations.

Two candidate root causes, in order of likelihood:

1. **A duplicated registry.** If rolldown emits its own copy of `vs/platform/instantiation/common/extensions.js` (which owns the module-level array `registerSingleton` pushes to) into each chunk, `register.all` registers into one copy while `StandaloneServices` reads the other, and exactly the five singletons that only `register.all` provides come up missing. Check with `npx vite build --sourcemap` and grep the sourcemap's `sources` for `instantiation/common/extensions` — more than one emitting chunk confirms it.
2. **Genuine ordering.** If the registry is shared, then `editor.api`'s evaluation snapshots the descriptors, and the fix is to make the registrations evaluate before core — e.g. a single Monaco barrel module that imports `features/register.all` first and re-exports the API, so no consumer can reach `editor.api` ahead of it.

Two stale comments to clean up while in here, both now describing code that doesn't exist:

- `src/lib/monaco/setup.ts`'s header says "it is imported at the top of `main.tsx`" — `main.tsx` doesn't reference Monaco; `MonacoEditor.tsx` loads it behind `React.lazy`.
- `configMonaco.ts`'s doc comment presents the dynamic `import()` as what prevents these errors. It does prevent the eager link, but not the errors.

## Impact

Cosmetic to the user in that editors still open — but 275 unhandled errors a day is 75% of this release's RUM error volume, which buries everything else, and #1592 already noted these fire per editor load. Also blocks reading #1609 as resolved: the deploy gap is closed, so anything still attributed to it needs re-checking.

## Notes

No customer identifiers included; view paths are route templates with parameters unresolved.

Start with src/lib/monaco/setup.ts and configMonaco.ts, then run npx vite build --sourcemap and grep the sourcemap for instantiation/common/extensions. Determine whether the registry is duplicated across chunks or registrations evaluate after editor.api, then verify the UNKNOWN service errors no longer occur and update the two stale comments.

Written by the indexing model from the issue text.