The survey landed, and neither census comment states a number any more

docs/handoffs/HANDOFF-cimport-ptr.md

@@ -61,10 +61,10 @@ rewritten comment at the head of `diff_bound` now says so.
 ## The comment at `lib/cimport.ml:1291`
 
 Rewritten from a promise into a description. The count it carried — "176 `declare-c`
-lines", against a real 196 — is gone rather than corrected, and the comment says why a
-census written beside a growing file is not a thing to maintain. `vendor/raylib/headers`
-carried the same rot ("425 declarations … 172 hand-written", really 463 and 196) and got
-the same treatment.
+lines", twenty short on the day it was read — is gone rather than corrected, and both
+comments now name the `grep` that answers the question instead of recording an answer that
+goes stale. `vendor/raylib/headers` carried the same rot, "425 declarations … 172
+hand-written", and got the same treatment. Neither file states a number any more.
 
 ## Then it was used
 
@@ -124,13 +124,12 @@ actually about is a **pointer reinterpretation**, which is not a checker arm.
   `defstruct`, every hand-written `declare-c` and every mapped constant against
   `raylib-5.5.h` and refuses to write when they disagree.
 - `bash web/examples/check.sh` green.
-- `spike/x86/survey.sh` was started detached on the finished tree and had not reported
-  when this session ended — it builds and runs 103 programs twice each and the `dev-*`
-  half of them hold daemons open. Nothing this change touches is below the IR: it is the
-  C-header importer, two raylib bindings, two examples and their tests, and no lowering
-  rule moved. The one surveyed program that changed is
-  `test/programs/raylib-codepoints.flan`, which passes on the LLVM path in `dune test`.
-  **Re-run it and confirm 103 MATCH / 0 DIFFER / 0 REFUSED before trusting this line.**
+- `spike/x86/survey.sh` on the finished tree: **103 MATCH, 0 DIFFER, 0 REFUSED** (38 skip
+  — 28 that do not compile on purpose, 8 with no main, 2 that run forever). Expected
+  rather than surprising: nothing here is below the IR, and the one surveyed program that
+  changed is `test/programs/raylib-codepoints.flan`. Run it detached — `setsid timeout
+  2400 spike/x86/survey.sh > log 2>&1 </dev/null` — because a foreground run takes the
+  signal sent to its process group and returns a spurious 143.
 
 ## Still open
 

lib/cimport.ml

@@ -1366,8 +1366,10 @@ let decl_source (d : Ast.decl) =
    immediately: every [declare-c] line in [vendor/raylib] was transcribed by
    hand from raylib's documentation, and until this nothing could say whether
    any of them was right. This says so, one at a time. (There is no count here
-   on purpose. The last one written down said 176 when there were 196, which is
-   the only thing a hand-maintained census of a growing file ever does.)
+   on purpose. The one that used to be said 176, and was twenty short by the
+   time anybody read it — which is what a hand-maintained census of a growing
+   file always ends up being. [grep -c '^(declare-c' vendor/raylib/*.flan] is
+   the answer and it is never stale.)
 
    Compared as *rendered Flan types* wherever the rendering is the whole story,
    and against the C spelling where it is not. Three differences are expected

vendor/raylib/headers

@@ -23,9 +23,11 @@
 #      hand-written ones can actually disagree, since the generated half came
 #      out of this header and agrees with it by construction. That is also why
 #      the hand-written lines were kept rather than replaced by generated ones.
-#      (There were counts here once. They said 425 and 172 and the truth had
-#      moved on to 464 and 197, which is what a census written into a comment
-#      beside a growing file always does.)
+#      (There were two counts here once, 425 and 172, and both had drifted by
+#      the time anybody checked them — which is what a census written into a
+#      comment beside a growing file always does. The generated half is
+#      `grep -c '^(declare-c' generated.flan` and the hand-written half is the
+#      same over the other .flan files here; neither number goes stale.)
 #
 # Why it is no longer optional. It used to be `?${FLAN_RAYLIB_H}`, and the
 # argument was that a build needs libraylib linkable and *not* raylib-devel