docs(assets): add GitHub social preview image variants

[pftom]

Summary

Add three candidate social preview PNGs under docs/assets/ for use as the repository's GitHub social preview image (Settings → General → Social preview).

• docs/assets/social-preview-cropped.png
• docs/assets/social-preview-padded.png
• docs/assets/social-preview-stretched.png

These are not referenced from any README; they're intended only as upload candidates for the repo's social card.

Test plan

• Decide which variant (cropped / padded / stretched) renders best at GitHub's 1280×640 social card slot.
• Upload the chosen variant under repo Settings → General → Social preview.
• (Optional) Drop the unused two variants in a follow-up cleanup commit.

Made with Cursor

[lefarcen]

Hey @pftom, clean asset addition — all three variants match GitHub's 1280×640 social preview spec, file sizes reasonable (409-484KB). 👍

Code review (Lens A — asset correctness): PNG format ✓, dimensions ✓, no embedded code/exif concerns for static display.

Reasoning review (Lens B — process completeness): A few non-blocking observations:

1. Test plan mentions manual upload workflow (pick variant → Settings → upload) but doesn't specify:

   • Who decides (design lead? maintainer consensus?)
   • Decision criteria beyond "renders best" (brand alignment? text legibility at small previews? mobile vs desktop preview differences?)
   • Timeline (before/after next release? marketing push?)

2. No documentation commit planned — Once a variant is chosen, consider adding a brief note somewhere (e.g., docs/assets/README.md or root README.md Social section) noting:

   • Which variant was selected and why
   • Original source/design file location (if reproducible)
   • Update process (when/how to regenerate if branding changes)

3. Alternative not discussed: Why three candidates instead of one confident choice upfront? If it's A/B testing for social engagement, tracking plan would help (e.g., switch after 1 week, compare GitHub stars/traffic). If it's just "let's see," could narrow to 1-2.

4. Cleanup step is optional — but leaving unused 2 variants in docs/assets/ forever will confuse future contributors ("which one is live?"). Consider either:

   • Moving unused variants to a candidates/ subfolder, or
   • Committing only the chosen one (delete others pre-merge)

All P3 — asset files themselves are good. Merge as-is if you want to decide the variant post-commit; just close the loop with docs/cleanup afterward. 🚀