Use premailer-rails strategies to inline email CSS without network fallback

[mroderick]

Problem

Emails previously relied on premailer fetching /assets/email.css from asset_host. After #2715 switched to asset_path("email.css"), the URL is correct but the CSS can still be stale when a proxy caches the resolved URL (see #2634). PR #2722 patched the symptom by inlining social-button colours directly in the template.

Solution

Keep app/assets/stylesheets/email.css as a real .css file and let premailer-rails inline it at delivery time using the :filesystem and :asset_pipeline strategies. This loads the stylesheet from the precompiled manifest without ever making an HTTP request to the asset host, so we keep CSS in a proper file while avoiding the stale-cache risk.

Changes

• Configure Premailer::Rails.config with strategies: [:filesystem, :asset_pipeline] in config/initializers/premailer.rb — removes the :network fallback
• Remove the inline background-color workaround from app/views/shared_mailers/_social.html.haml — premailer inlines the .soc-btn.* rules from email.css
• Add shared RSpec example behaves_like_email_with_social_links.rb that asserts all social-button colours are inlined and no external CSS link appears in the delivered email
• Include the shared example in all five mailer specs that render shared_mailers/_social
• Update the email assets README

What stayed the same

• app/assets/stylesheets/email.css — unchanged
• app/views/shared_mailers/_header.html.haml — unchanged, still links email.css via asset_path

Verification

• bundle exec rspec spec/mailers/ — 75 examples, 0 failures
• make test — 1159 examples, 0 failures