feat(showcase): implement the 'Cougr Verified' badge check

[salazarsebas]

Part of #240

Background

The showcase needs a credible trust signal, otherwise it is just a list. EXAMPLE_STANDARD.md already defines exactly what "canonical" means (module layout, README structure, dependency hygiene, testing categories) and scripts/enforce_hygiene.sh already implements much of that check programmatically. docs/strategy/05-ecosystem-vision.md proposes formalizing this into a visible "Cougr Verified" badge, reusing existing logic rather than inventing a new standard.

Objective

Implement an automated check that evaluates an example against the existing EXAMPLE_STANDARD.md checklist and produces a pass/fail "Cougr Verified" status that the showcase (sibling sub-issue) renders as a badge.

References

• EXAMPLE_STANDARD.md (the checklist this issue automates, not redefines)
• scripts/enforce_hygiene.sh (existing partial implementation to extend, not replace)
• Dependency: the cougr check CLI command (CLI epic) is the natural home for this logic if that epic lands first; if not, this issue may implement it standalone and the CLI epic should later consume it, avoid building two divergent implementations of the same checklist.

In scope

1. A checklist runner (reusing cougr check from the CLI epic if available, or standalone otherwise) that evaluates a given example directory against every criterion in EXAMPLE_STANDARD.md's canonical-vs-transitional checklist.
2. Output format the gallery generator can consume directly (e.g. a pass/fail plus a list of unmet criteria, written to the catalog metadata or a sibling report file).
3. Run against all 10 currently-canonical examples as a validation pass; all 10 must pass (if any doesn't, that's a signal worth raising, not silently working around).
4. Wired into CI so a canonical example that regresses against the standard is caught automatically, not just at showcase-build time.

Out of scope

• Evaluating the 29 transitional examples for canonical promotion; that migration work is already tracked through the project's existing example-standardization effort (see recent PRs refactor(examples): standardize arcade examples on GameApp module layout #226, #226 standardize arcade examples on GameApp module layout FIXED #228, docs(examples): apply EXAMPLE_STANDARD to board and puzzle examples #233) and is out of scope here.
• Any visual badge design (that's the design-system epic's territory; this issue only produces the underlying pass/fail data).

Definition of done

• Running the check against all 10 canonical examples produces 10 passes.
• Running the check against a deliberately non-compliant fixture produces a specific, correct list of failing criteria.
• The check runs in CI, not only on demand.

[victor-134]

@victor-134 has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

Kindly assign I can implement sir

ℹ️ Repo Maintainers: To accept this application, review their application or assign @victor-134 to this issue.

[Blessed-Femi]

@Blessed-Femi has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

I will love to work on this

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Blessed-Femi to this issue.

[drips-wave]

Congratulations, @victor-134! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on July 30, 2026.

🧑‍💻 @victor-134: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊