[RUM] Production stuck on v2.156.4 for 12 days — merged #1592 Monaco DI fix never shipped, now 91% of prod errors

## Summary

Production (`fabric.harper.fast`) is still serving **v2.156.4**, tagged 2026-07-29. Five releases
have shipped since — **v2.156.5, v2.156.6, v2.157.0, v2.158.0, v2.159.1** — and none have reached
users. As of today (2026-08-11) that is a **12-day gap**.

The visible consequence: the Monaco DI fix for #1592 landed in **v2.156.5** and #1592 was closed
2026-07-30, but because production never moved off v2.156.4 the bug is still live. It is now
**91% of all production RUM error events** (772 of 846 in the last 24h).

This is *not* a duplicate of #1592 — that issue tracked the code defect, and the code fix in #1593
is correct and merged. This tracks the delivery gap: fixes are being marked done while production
keeps running the release they were meant to fix.

## Evidence that production is on v2.156.4

RUM, last 24h, sessions grouped by app version:

| version | sessions |
|---|---|
| **v2.156.4** | **166** |
| v2.159.1 | 1 |

Confirmed independently against the bundle production actually serves — no RUM attribute involved:

- `https://fabric.harper.fast/assets/index-D_fsIlUa.js` initializes RUM with
`env:'prod', version:'v2.156.4'`.
- The eager entry chunk still statically imports `./editor.api-OBQnf1nL.js`, i.e. Monaco is still
linked into an eager chunk — the exact invariant #1593 restored.
- None of the five service names (`actionWidgetService`, `ICodeLensCache`, `IInlayHintsCache`,
`ISuggestMemories`, `treeViewsDndService`) appear in any eager chunk, so their `registerSingleton`
calls still land in a lazy chunk that evaluates after Monaco has built its service collection.
- `error.file` on every one of these errors is
`node_modules/.pnpm/monaco-editor@0.56.0/.../vs/base/common/errors.js`.

The `vendor-core-*` / `vendor-tanstack-*` chunk hashes in the RUM error stacks match the hashes
served right now, so the errors are coming from the currently-deployed build.

## Impact

Monaco DI errors, per 24h window, normalized against total sessions:

| window | total sessions | Monaco error events | affected sessions | % of sessions |
|---|---|---|---|---|
| last 24h | 167 | 772 | 40 | **24%** |
| −24 to −48h (Sun) | 53 | 50 | 4 | 8% |
| −48 to −72h (Sat) | 50 | 248 | 9 | 18% |
| −72 to −96h | 86 | 235 | 18 | 21% |
| −96 to −120h | 139 | 542 | 33 | 24% |

Worth stating plainly: this is **steady, not a spike**. Raw counts look like a 15× jump against the
previous day, but that day was a Sunday with a third of the traffic; normalized, it has been running
at ~18–24% of sessions all week. Five unhandled errors per editor-creating page load.

Functionally, the five services back code lens, inlay hints, suggest-memory ranking, the
code-action/lightbulb widget, and tree-view drag-and-drop — all silently degraded in the editor,
which is what #1592 already described.

## What to check

1. Why has the production deploy not advanced past v2.156.4 since 2026-07-29? Is the release job
failing, waiting on a manual approval, or pinned deliberately? (No GitHub Deployments records
exist for this repo, so the promotion happens outside GitHub's deployment API and isn't visible
here.)
2. Whether anything else closed in the last 12 days is likewise "fixed" but not actually live —
v2.156.5 through v2.159.1 all contain unshipped work.
3. Worth considering an alert on the gap between the newest tag and the `version` RUM reports, so a
stalled promotion surfaces on its own rather than via an error triage two weeks later.

## Not filed separately

For the record, everything else in the last 24h is already tracked or long-standing:

- 400s on the direct-to-instance operations API — #1602
- 500s on instance/cluster `/operation` polling — #1527
- Core Web Vitals collection dead (so no p75 to compare against) — #1570
- `window.lintrk is not a function` (3 events, 1 session, first seen v2.134.1), `Failed to load the
JS script of the agent` (2 events), assorted handled 403/404/409/timeout — all low-volume and
first seen many releases ago, nothing new.

---
*Filed from the daily Datadog RUM review. RUM app `f590deee-4bac-49b4-a202-3b6963d9721d`, window
2026-08-10 → 2026-08-11.*

Start by checking why production still serves the bundle at /assets/index-D_fsIlUa.js with version v2.156.4, then trace the release promotion path for v2.156.5 through v2.159.1; the issue notes that no GitHub Deployments records exist. Done means identifying and resolving the stalled, failed, or intentionally pinned promotion, verifying the deployed version and Monaco bundle invariant, and assessing whether a release-to-RUM gap alert is feasible.

Written by the indexing model from the issue text.