✨ Ship ErrorPage default symbol & logo as data: URIs

[damienlagae]

Summary

Follow-up to #20 (closed by smoke-test feedback on consumer apps needing to ship the logo asset).

• Ships the default symbol and logo as data: URIs embedded in the bundle — consuming apps no longer need to provide any image asset for the error page to render out of the box.
• Lazy loaded from two text files (src/Component/Layout/Defaults/error_page_{logo,symbol}.txt) with static memoization, so the heredoc-sized base64 strings stay out of the PHP class body.
• The Twig template detects data: prefixed values and renders them inline, falling back to asset() for traditional paths. Custom overrides keep working unchanged.

Why data URIs only for ErrorPage (and not for EmailLayout from #21)

Data URIs in <img src> are reliably rendered by every modern browser, so they're a great fit for HTTP-served pages like the error template. In emails, however, Outlook desktop blocks them and Gmail strips them in some contexts — that's why EmailLayout keeps the email.image() CID-embedding approach.

Test plan

• PHPUnit: 206/206 (1 new test verifying that custom symbol/logo paths still override the data URI defaults)
• php-cs-fixer: clean
• phpstan: no errors
• Smoke test in a consumer app: render a 404 with no symbol/logo overrides, confirm the page is fully self-contained (no broken images, no 404s on the watermark)

[damienlagae]

Smoke-tested in Impala — confirmed the consumer-side promise of the PR.

What I verified

• 404 page rendered with no symbol / logo overrides → response body contains src="data:image/svg+xml;base64,…" (symbol, 1.5 KB SVG) and src="data:image/png;base64,…" (logo, ~15 KB PNG)
• Page total weight: 60 KB on the wire — fully self-contained
• Removed Impala's /public/images/enabel-symbol.png and enabel-logo-email.png, reloaded → identical render, no broken images, no 404s on the watermark
• Restored Impala's assets after the test

One thing to flag

The embedded default logo PNG (200×200) is just the Belgian-flag-coloured "y" symbol, without the "Enabel" wordmark that the previous default (enabel-logo-email.png) carried. Comparing the renders side-by-side, the bottom-of-page branding is now noticeably weaker (just the glyph vs. "Enabel" + glyph). Two options worth considering:

• intentional simplification — fine, but maybe call it out in the doc / changelog so consumers know the visual changed
• oversight — swap the logo data URI for a base64-encoded version of the original enabel-logo-email.png (still under ~30 KB)

Functionally LGTM, just want a call on the branding intent before tag.

[damienlagae]

Updated in 0e747e5 — replaced the placeholder logo with the official enabel-logo-email.png (150×50, 4.8 KB → ~6.6 KB base64). The page total now drops to ~50 KB on the wire (vs 60 KB previously) since the official logo is also smaller than the symbol-only PNG I'd grabbed.

Tests still green (the assertions only check the data:image/png;base64, prefix), no template/code changes needed. Ready for a re-check whenever you have a sec.