fix(ci): inject Sentry debug IDs at build time so uploaded source maps match the deployed bundles

[ThibaudDauce]

Sentry stacks on prod point at the wrong functions. getsentry/action-release injects debug ids by default before uploading, and sentry-cli sourcemaps inject prepends 2 lines to every bundle and shifts its source map accordingly. It runs in the sentry job on a copy nobody deploys: docker downloaded the same artifact before, so prod serves the bundle without the ids and every frame resolves 2 lines too early.

The served _nuxt/BCgWgZak.js has 35 lines and no //# debugId=. Resolving the real throw position of the Cannot destructure property 'bum' issue through both maps:

bundle 4:33557
  served map   → runtime-core.esm-bundler.js 6833:10   unmountComponent
  injected map → runtime-core.esm-bundler.js 1316:29   prepareAnchor

Sentry showed prepareAnchor, so we spent a while looking at Teleport for a crash in unmountComponent.

Injection moves to the build job, before the artifact upload, and the sentry job keeps doing the upload with inject: false. Ran a local build then the injection step on its output, over the 490 chunks:

avec //# debugId=                  : 490
avec l'id runtime _sentryDebugIds  : 490
maps portant la clé debugId        : 490
les trois concordent               : 490

DW9KlUNB.js : {bum: en 6:33557 → runtime-core.esm-bundler.js 6833:10

I tried letting the Sentry bundler plugin inject instead, since it runs in renderChunk and shifts nothing at all. It doesn't work here: it only writes the runtime _sentryDebugIds snippet, never the //# debugId= comment nor the debugId key in the map, and sentry-cli sourcemaps upload needs both (--debug-id-reference help: "By default Debug ID reference has to be present both in the source and the related sourcemap"). It only writes them at upload time, on temp copies, which is the part we don't want in the build. Running both injectors is worse: the chunk ends up with sentry-dbid-c57fb1d3… at runtime and //# debugId=026fe91a… in the artifact.