Blog post: announce Testify's Paparazzi support

[AndroidTestifyBot]

Is your feature request related to a problem? Please describe.

Testify's Paparazzi support shipped, but was never announced. The work is done and invisible, which wastes most of its community value.

Spun off from #278, which is now closed as delivered.

This feedback relates to:

• The Kotlin library
• The Gradle plugin
• The IntelliJ Platform plugin
• The sample code
• The documentation

What already shipped

• Add Testify support for Paparazzi snapshots to Intellij plugin #305 (89d03d19) — Paparazzi support in the IntelliJ plugin: a Paparazzi TestFlavor, hasPaparazziRule() detection that walks nested rule fields, verifyPaparazzi$Variant / recordPaparazzi$Variant from the gutter icon, and a Paparazzi-aware pull that moves failure PNGs from build/paparazzi/failures into src/test/snapshots/images.
• Add sample app demonstrating Testify usage with Paparazzi #303 (02c6f9fc) — Samples/Paparazzi, a port of the Flix app rendered on the JVM under src/test, composable for composable and fixture for fixture against the on-device Flix sample.
• Re-record sample and library baselines on an API 37 emulator #309 (7dd80e28) — both sets of baselines re-recorded on an API 37 emulator, so the comparison is current.

Describe the solution you'd like

A post on docs/blog/ covering:

1. What it does — one gutter icon, two engines. Record and verify Paparazzi snapshots from the IDE the same way you already do Testify screenshots.
2. The side-by-side comparison — Samples/Flix and Samples/Paparazzi are deliberately the same app, which is exactly the comparison a team evaluating both tools is trying to make. Cover where on-device and JVM rendering differ in fidelity, speed and setup cost.
3. When to reach for which — honest guidance rather than advocacy.
4. The positioning — Testify as the tooling and workflow layer over whichever screenshot engine a team picks, not a competitor to all of them.

Point 4 is the part worth stating publicly, because it also sets up #261 (Compose Preview testing), which extends the same pattern to a third engine.

Describe alternatives you've considered

• Do nothing — the feature stays undiscovered. The IDE plugin is the only engine-agnostic part of Testify, and nobody knows it drives Paparazzi.
• A docs page instead of a blog post — worth doing as well, but a docs page only reaches people already using Testify. The audience here is teams currently choosing between tools.

Additional context

The blog already has a working cadence and precedent (2023-09-23-gradle-managed-device.md, 2025-02-01-bitrise.md, 2026-08-20-samples-update.md), so there's no infrastructure cost.

Rough effort: ~1 day including screenshots of the gutter workflow.

Related: #278 (closed as delivered), #279, #261.