fix(census): stop hiding findings behind a question-outcome count, and correct the PHP record

PHP is not silent. Paid Memberships Pro establishes findings, including a true positive, and
this project's own instrument is why it looked otherwise.

The census harness ordered its verdict on completion before findings, so a family with eighteen
findings and no completed question reported "asked but no question completed". Findings are now
checked first: a question-outcome count is bookkeeping and cannot hide the thing being censused.
NodeGoat and VAmPI were never affected, because they complete every question and their verdicts
reached the findings check. The scan summary now also carries the total findings and the outcome
status counts, so the two numbers can be seen disagreeing instead of one silently winning.

The second mistake was mine rather than the harness's: only the 500-region runs had been looked
at, which are the ones that time out.

What PHP actually detects on PMPro. At 25 regions, 19 findings in seven minutes with no timeout;
at 100 regions, 43 findings in twelve minutes with no timeout. Among them adminpages/
discountcodes.php:749, where sanitize_text_field($_REQUEST["s"]) reaches
$wpdb->get_results($sqlQuery, OBJECT) through `$sqlQuery .= "WHERE code LIKE '%$s%' "` with no
prepare. That is the class of CVE-2023-23488, which php.toml's own comment names as the reason
those WordPress sanitizers are kept out of the sanitizer list. The prediction and the measurement
agree.

The precision cost beside it is measured too: output encoding reports eighteen findings at 25
regions and the three sampled are all properly escaped, two with esc_attr and one coerced with
intval. Those escapers are absent from a sanitizer list that is flat across families, because
none of them stops SQL injection. Keeping the injection finding costs this family its precision.

The scale limit is roughly one to two seconds per question. 25 and 100 regions complete cleanly;
500 regions asks 2,526 questions, needs more than the 1,800-second ceiling and is killed.

Four things are measured NOT to be the problem: the malformed-CPG bug (fixed in 4.0.625, verified
on the real trigger file), the dataflow overlay (42 s on the full 637-file graph), the engine
version (4.0.625 and 4.0.631 indistinguishable), and the bundled Stripe, Braintree and Twocheckout
SDKs under includes/lib that the vendored list does not cover -- that was my hypothesis for the
cost and the overlay measures 42 s with them and 37 s without, so it is refuted.

What remains is bookkeeping, not detection: questions_completed is zero in every PHP run including
the ones that find things, with cross_partition_semantics_unresolved and
partition_file_census_incomplete present throughout. The admission policy reads those outcomes.

1,417 tests pass, eighteen skipped.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01EmM1j46qgKMh3zqD1QMwEo

benchmarks/push/family_census.py

@@ -85,6 +85,10 @@ def main() -> int:
         "degradations": [str(d.get("reason")) for d in result.degradations],
         "questions_total": len(result.question_outcomes),
         "questions_completed": sum(1 for q in result.question_outcomes if q.status == "completed"),
+        "findings_total": len(result.findings),
+        # Why the outcomes say what they say, counted rather than inferred: a family can find something while
+        # every one of its questions is recorded unresolved, and the two numbers then disagree in public.
+        "outcome_status": dict(collections.Counter(q.status for q in result.question_outcomes)),
     }
 
     asked = collections.Counter(q.identity.family for q in result.question_outcomes)
@@ -111,17 +115,24 @@ def main() -> int:
             "questions_completed": completed.get(family, 0),
             "findings": len(found.get(family, [])),
             "rungs": dict(collections.Counter(item["rung"] for item in found.get(family, []))),
-            "examples": found.get(family, [])[:3],
+            "examples": found.get(family, [])[:10],
             # The distinction that matters: a family that answered and found nothing is a different
             # statement from one that could not answer, and neither is "clean".
+            #
+            # Findings are checked FIRST, and that order is the whole point. It used to ask about completion
+            # before findings, so a family that established 18 findings on a PHP plugin while no question
+            # outcome was marked completed reported "asked but no question completed" -- and a census whose
+            # job is to say what each family finds reported nothing for a repository that had found a real
+            # SQL injection. A question-outcome count is a statement about bookkeeping; a finding is the
+            # thing being censused, and it cannot be hidden behind the other.
             "verdict": (
-                "region offered, no question asked"
+                "establishes findings"
+                if found.get(family)
+                else "region offered, no question asked"
                 if not asked.get(family)
                 else "asked but no question completed"
                 if not completed.get(family)
                 else "answered, nothing found"
-                if not found.get(family)
-                else "establishes findings"
             ),
         }
         for family in families