Make Server-Timing opt-in in Astro integration (default off)

[0tarof]

I'm running EmDash through the Astro integration (emdash/astro) on Cloudflare Workers and noticed that public, unauthenticated responses include the full Server-Timing header. The finalizeResponse helper in packages/core/src/astro/middleware.ts sets the header unconditionally whenever serverTimings.length > 0.

(This only affects setups that go through the Astro integration — direct API consumers of emdash never hit this middleware.)

Here's an actual response from a public page on my deployment:

server-timing: setup;dur=17;desc="Setup probe",
               rt.db;dur=34;desc="DB init + migrations",
               rt.plugins;dur=15;desc="Plugin states",
               rt.sandbox;dur=0;desc="Sandboxed plugins",
               rt.hooks;dur=19;desc="Exclusive hook resolution",
               rt.cron;dur=0;desc="Cron init (recovery deferred post-response)",
               render;dur=3;desc="Page render",
               mw;dur=103;desc="Total middleware"

This exposes more implementation detail than I'd normally expect to send to an anonymous visitor — that the site is running EmDash, which subsystems are wired up (plugins, sandbox, cron, hooks), and the cold/warm timing profile. There's no opt-out today.

The W3C spec addresses this case directly:

the server can also use relevant logic to control which metrics are returned, when, and to whom — e.g. the server may only provide certain metrics to correctly authenticated users and nothing at all to all others.
— W3C Server-Timing §4 (MDN's Server-Timing page echoes the same)

My first instinct would be to make this opt-in via config — something like a serverTiming field on EmDashConfig, defaulting to off:

emdash({
  // default: false (no emission)
  serverTiming: true,                    // always on
  // serverTiming: import.meta.env.DEV,  // dev / preview only
})

But I'm not sure if there was an intentional reason to expose these timings on public responses by default — maybe RUM compatibility, or something I'm missing.

The only place that emits Server-Timing is finalizeResponse, so the implementation should be small. EmDashConfig is shared between the Astro integration and direct API consumers, but the option would only affect the integration path.

This feels related to #674 (Nonce-Based CSP by Default) — same theme of tightening defaults on public responses without changing the admin/dev experience.

In the meantime I'm stripping the header at the Cloudflare Workers fetch entrypoint. Stripping inside Astro middleware doesn't work — finalizeResponse re-applies it after next() returns. It's a workaround, not a fix.

Would you be open to making this opt-in, or is there something I'm missing about why it's on by default?