feat: stable static headers

[ematipico]

Changes

Closes #14952

This PR stabilise experimentalStaticHeaders.

It doesn't add any new APIs, and it keeps the existing semantics.

Testing

Updated the fixtures, tests should still pass

Docs

withastro/docs#13159

[changeset-bot]

🦋 Changeset detected

Latest commit: a863102

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

⚠️ Package Trust Level Decreased

Caution

Decreased trust levels may indicate a higher risk of supply chain attacks. Please review these changes carefully.

📦 Package	�� Before	🔓 After
eslint-plugin-regexp	trusted-with-provenance	none
@cloudflare/kv-asset-handler	trusted-with-provenance	none
@cloudflare/unenv-preset	trusted-with-provenance	none
workerd	trusted-with-provenance	none
@sveltejs/vite-plugin-svelte-inspector	trusted-with-provenance	provenance
@sveltejs/vite-plugin-svelte	trusted-with-provenance	provenance
jsdoc-type-pratt-parser	trusted-with-provenance	none
miniflare	trusted-with-provenance	none
youch	provenance	none
@cloudflare/workerd-darwin-64	trusted-with-provenance	none
@cloudflare/workerd-darwin-arm64	trusted-with-provenance	none
@cloudflare/workerd-linux-64	trusted-with-provenance	none
@cloudflare/workerd-linux-arm64	trusted-with-provenance	none
@cloudflare/workerd-windows-64	trusted-with-provenance	none
wrangler	trusted-with-provenance	none

[matthewp]

Here's the issue this is for: #14952

[matthewp]

I don't quite understand what this API is for. I understand that for CSP we have some headers that we want to tell the adapters about. What is wrong with the approach we're already doing here? Are there other use-cases?

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing feat/static-headers (a863102) with next (0a9777e)¹}

Summary

✅ 9 untouched benchmarks
⏩ 9 skipped benchmarks²

Footnotes

1. No successful run was found on next (cdb99c8) during the generation of this report, so 0a9777e was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

2. 9 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩