The requested project count uses project entities, while check counts use
individual check-event entities. North has 2 projects, 4 check events and
3 passed check events. South has 1 project, 2 check events and 1 passed
check event. West has 1 project and no check events, so its checks and
passed counts are both 0. The full three-row output totals 4 projects,
6 check events and 4 passed check events.

P1 occurs three times in the raw joined diagnostic because it has three
different check IDs. C1 and C2 are separate pass events, not duplicate
outcome records to discard. P3 occurs twice because it has C5 and C6.
P4 has no event: its null right-side columns do not describe a new check.
The seven joined rows are matching combinations plus the unmatched P4
row, not a seven-project or seven-check inventory.

The corrected query first aggregates actual checks to one row per project,
then joins that result to the four project rows. COUNT(*) in the outer
query now counts projects; zero event counts are supplied with COALESCE.

The baseline wrong query, diagnostic and corrected query were actually
executed locally using SQLite 3.51.0 against this fictional fixture.
All four prescribed data cases matched independently handwritten expected
rows. No model was tested, and no production database or customer data
was accessed. These observations do not establish performance at scale
or correctness for a different schema or question.