fix(loader): label loader_cache with the block key, not the resolve chain

`loader_cache` and `resolver_latency` were labelled with `ctx.resolverId`, which
carries the full resolve chain:

    Categories@sections.variants.1.value.5.sections.0.section.page
    SearchResults Global@sections.0.section.page
    Categories@sections.variants.1.value.2.jsonLD

Every section position, of every variant, of every page becomes its own time
series. That is an identifier, not a dimension.

Measured on the production ClickHouse:

    distinct `loader` values, 3h window
      fila-store          3,684
      todolivrooficial    3,478
      montecarlo          2,209
      farmrio             1,469
      happybooksoficial   1,028
      fleet total        21,849

Against the budget documented in our own o11y guide — >1,000 per site is
forbidden as an alert dimension and >100 fleet-wide as a cross-fleet
aggregation — five sites are over and the fleet figure is 218x over. The cost
is real: `loader_cache` is 11,485,954 of 14,998,196 rows in otel_metrics_sum
over 3h, i.e. 76.6% of the whole table, and that table holds 48.4 GB.

For contrast, `cache_hit` covers 194 tenants in 9 series, and the
@decocms/start runtime does the equivalent job with 13 distinct
`deco.cache.profile` values fleet-wide.

The fix uses the block key that `adapt` already receives — the loader's module
path, e.g. `vtex/loaders/legacy/productListingPage.ts` — which is bounded by
the number of loader modules in the app. It is threaded into `wrapLoader` as a
new parameter; `wrapLoader` is module-private with a single call site.

What is lost: the metric can no longer distinguish two instances of the same
loader sitting in different sections. That trade is deliberate. The chain is
still carried on error logs, where high cardinality is acceptable because they
are read by point lookup rather than aggregated — and the o11y guide draws
exactly that line: high-cardinality attributes are fine for filtering and point
lookups, forbidden as aggregation keys.

`ctx.resolverId` is kept as a fallback so behaviour is unchanged if a caller
ever passes an empty key.

Verified: deno check blocks/loader.ts clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: nicacioliveira

blocks/loader.ts

@@ -188,6 +188,13 @@ const wrapLoader = (
   }: LoaderModule,
   resolveChain: FieldResolver[],
   release: DecofileProvider,
+  /**
+   * The block key — the loader's module path, e.g.
+   * `vtex/loaders/legacy/productListingPage.ts`. Used as the metric label
+   * instead of `ctx.resolverId`, which carries the full resolve chain and is
+   * unbounded. See the `loader` constant below.
+   */
+  blockKey: string,
 ) => {
   const [cacheMaxAge, mode] = typeof cache === "string"
     ? [MAX_AGE_S, cache]
@@ -208,7 +215,21 @@ const wrapLoader = (
       req: Request,
       ctx: FnContext<State, any>,
     ): Promise<ReturnType<typeof handler>> => {
-      const loader = ctx.resolverId || "unknown";
+      // Metric label. Deliberately the block key and NOT `ctx.resolverId`:
+      // resolverId carries the full resolve chain, e.g.
+      // `Categories@sections.variants.1.value.5.sections.0.section.page`, so
+      // every section position of every variant of every page becomes its own
+      // time series. Measured in production that reached 3,684 distinct values
+      // on a single site and 21,849 across the fleet, against a documented
+      // budget of 1,000 per site and 100 fleet-wide — and `loader_cache` alone
+      // became 76.6% of all rows in otel_metrics_sum.
+      //
+      // The block key is bounded by the number of loader modules in the app,
+      // which is what the @decocms/start runtime already uses for the
+      // equivalent metric (13 distinct values fleet-wide). The chain is not
+      // lost: it still travels on error logs, where high cardinality is fine
+      // because they are read by point lookup rather than aggregated.
+      const loader = blockKey || ctx.resolverId || "unknown";
       const start = performance.now();
       let status: "bypass" | "miss" | "stale" | "hit" | undefined;
 
@@ -365,7 +386,7 @@ const loaderBlock: Block<LoaderModule> = {
     wrapCaughtErrors,
     (props: TProps, ctx: HttpContext<{ global: any } & RequestState>) =>
       applyProps(
-        wrapLoader(mod, ctx.resolveChain, ctx.context.state.release),
+        wrapLoader(mod, ctx.resolveChain, ctx.context.state.release, key),
       )(
         props,
         ctx,