fix(head): avoid CSP warnings when disabled

[logelog]

What does this PR do?

Avoids Astro CSP warnings from EmDashHead when a host project has not enabled Astro's built-in CSP support.

This is a follow-up to #1695. The JSON-LD integration currently reads Astro.csp before it knows whether CSP is enabled. Astro 7 warns on every affected production render even when the page does not need CSP handling.

The fix:

• records the normalized CSP-enabled state in EmDash's virtual config;
• keeps access to Astro.csp lazy when CSP is disabled;
• preserves JSON-LD script hash registration when CSP is enabled;
• adds regression coverage for both paths.

Type of change

• Bug fix
• Feature
• Refactor
• Translation
• Documentation
• Performance improvement
• Tests
• Chore

Checklist

• I have read CONTRIBUTING.md
• pnpm --filter emdash typecheck passes
• Changed-file type-aware lint passes
• Targeted tests pass
• pnpm format:check passes
• I added regression coverage
• No user-visible admin strings were added
• I added a changeset
• New features link to an approved Discussion (not applicable; bug fix)

Validation

• pnpm --filter emdash exec vitest run tests/unit/plugins/page-metadata.test.ts - 33 tests passed
• pnpm --filter emdash typecheck
• changed-file type-aware oxlint
• pnpm format:check
• git diff --check
• production SSR reproduction with the simple demo:
  • current main: request returns 200 and logs context.csp was used ... but CSP was not configured
  • this branch: request returns 200 with no CSP warning

[changeset-bot]

🦋 Changeset detected

Latest commit: 28628ee

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

This PR includes changesets to release 16 packages

Name	Type
emdash	Patch
@emdash-cms/cloudflare	Patch
@emdash-cms/sandbox-workerd	Patch
@emdash-cms/fixture-perf-site	Patch
@emdash-cms/perf-demo-site	Patch
@emdash-cms/cache-demo-site	Patch
@emdash-cms/do-demo-site	Patch
@emdash-cms/do-solo-demo-site	Patch
@emdash-cms/admin	Patch
@emdash-cms/auth	Patch
@emdash-cms/blocks	Patch
@emdash-cms/gutenberg-to-portable-text	Patch
@emdash-cms/x402	Patch
create-emdash	Patch
@emdash-cms/auth-atproto	Patch
@emdash-cms/plugin-embeds	Patch

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

[emdashbot]

This is the right fix for the right problem. Capturing the CSP-enabled state in the virtual config and keeping Astro.csp behind a lazy getter avoids Astro’s warning on non-CSP sites while preserving JSON-LD script-hash registration for sites that do enable CSP. The change is additive, narrowly scoped, and fits EmDash’s existing virtual-config architecture.

What I checked:

• Diff and full changed files (EmDashHead.astro, page/metadata.ts, astro/integration/index.ts, virtual-modules.d.ts, tests, changeset).
• Virtual-module serialization path (serializableConfig → generateConfigModule).
• All Astro.csp / insertScriptHash / security.csp usage sites in the repo.
• AGENTS.md conventions (changeset, imports, tests).

Headline: implementation is correct, but the new regression test asserts a side-effect order that Promise.all does not guarantee, which is likely to flake. I also noted an optional import-convention alignment.

[emdashbot]

[needs fixing] registerJsonLdCspHashes registers hashes with await Promise.all(scripts.map(async …)), so the two async crypto.subtle.digest calls run concurrently. The order in which their insertScriptHash side effects execute is not guaranteed by Promise.all, making the toHaveBeenNthCalledWith(1, …) / toHaveBeenNthCalledWith(2, …) assertions potentially flaky. Since CSP hash order has no functional significance, assert set membership instead of order.

Suggested change

	expect(getCsp).toHaveBeenCalledOnce();
	expect(insertScriptHash).toHaveBeenCalledTimes(2);
	expect(insertScriptHash).toHaveBeenNthCalledWith(1, await createSha256CspHash(scripts[0].json));
	expect(insertScriptHash).toHaveBeenNthCalledWith(2, await createSha256CspHash(scripts[1].json));
	const hash0 = await createSha256CspHash(scripts[0].json);
	const hash1 = await createSha256CspHash(scripts[1].json);
	expect(getCsp).toHaveBeenCalledOnce();
	expect(insertScriptHash).toHaveBeenCalledTimes(2);
	expect(insertScriptHash).toHaveBeenCalledWith(hash0);
	expect(insertScriptHash).toHaveBeenCalledWith(hash1);

[emdashbot]

[suggestion] AGENTS.md’s Imports convention asks for a // @ts-ignore - virtual module comment above imports from virtual:emdash/config. Other files in the repo follow this pattern. Consider adding the comment for consistency, especially since .astro components are excluded from the core tsconfig.json.

Suggested change

	import virtualConfig from "virtual:emdash/config";
	// @ts-ignore - virtual module
	import virtualConfig from "virtual:emdash/config";