[2.x] fix: resolve email logo URL via flarum-assets disk

[imorland]

Summary

The HTML email layout built the logo <img src> as:

$url->to('forum')->base() . '/assets/' . $settings->get('logo_path')

On installs serving assets from a remote bucket or CDN, the actual logo file lives at the flarum-assets disk's resolved URL — not under forum-base/assets/. Every email those installs rendered showed a broken logo.

Resolve the logo URL via the same flarum-assets disk that ForumResource::getLogoUrl() uses for the frontend, and share it to email views as a precomputed $logoUrl.

Fixes #4604

Changes

• framework/core/src/Mail/MailServiceProvider.php — boot() now resolves logo_path against the flarum-assets disk and shares the result as logoUrl to all views (computed once per request boot, cheap).
• framework/core/views/email/html.blade.php — read the precomputed $logoUrl instead of the broken concatenation; no @inject added.

Compatibility

• Local-disk installs (default): the flarum-assets disk's url() returns https://forum.example.com/assets/<path> — same URL the old concatenation produced. No observable change.
• S3 / CDN installs: the disk now returns the actual asset URL. Logos render where the file is.
• Third-party extensions that already pass their own $logoUrl to an email render via ->with('logoUrl', ...) still win — Laravel's local with() overrides global share().

Test plan

• Existing mailer-related integration tests pass (7/7).
• Manual: send a test email on a local-disk install — logo renders unchanged.
• Manual on S3-backed install: send a test email — logo loads from the bucket/CDN URL.

Notes

• No automated test for the rendered HTML body — would need to capture mailer output and inspect the <img src> attribute, which is heavyweight relative to the size of this change. The fix mirrors a pattern already exercised everywhere else in core that resolves asset URLs.
• The plain-text email template doesn't include the logo, so no change there.
• Dark-mode logo handling in emails is out of scope — most mail clients can't reliably swap images per dark mode anyway.