Prove imported webfont materialization through live WordPress capture

[chubes4]

Problem

Fixture 37 declares Inter weights through CSS @import and computes the same font-family, size, weight, line-height, and tracking in source and candidate, yet candidate glyph metrics prove the intended face is unavailable/substituted.

Example from run 4487b543-f197-40b5-b5e9-a2727c698b55: h2#artists-heading is 278.016px wide in source and 336.344px in candidate despite identical declared typography. Header and body text show the same broad drift.

Ownership spans Blocks Engine FontMaterializationPlanBuilder::fromWebFontSources() and SSI font overlay materialization. The run does not retain enough handoff evidence to identify whether plan generation, download, overlay write, registration, or screenshot readiness failed: materialization receipt, transformer package/reference/version, and WordPress site plan are missing.

Expected

The generic artifact-to-WordPress path materializes declared webfont faces/weights, records complete provenance and receipt evidence, waits for document.fonts readiness, and proves loaded runtime faces before visual capture.

Acceptance criteria

• CSS @import webfont sources produce a complete materialization plan and durable receipt.
• SSI receives and installs every declared face/weight through the generic handoff.
• Visual capture records document.fonts readiness and loaded face/weight evidence.
• Missing/download-failed/substituted faces fail with actionable diagnostics instead of silent fallback.
• End-to-end live WordPress coverage proves representative glyph metrics against source.
• Fixture 37 typography width drift materially decreases without fixture-specific logic.

Evidence

Run 4487b543-f197-40b5-b5e9-a2727c698b55; screenshots and DOM snapshots are persisted under that run.

AI assistance

OpenAI GPT-5.6 Sol via OpenCode compared computed typography and traced the cross-repository materialization boundary. Chris Huber owns the report.