What was run, and the one thing a green build does not mean

The lane's record in FIX.org: dune test green before and after the rebase,
test_dev.exe run directly because a cached run swallows its label, and
@sanitize clean on the committed source, which is where the
two-thousand-instance migration under collection is actually looked at.

The line worth keeping is about the rebase. dune build does not compile
flan_dyn.c — it is a string the compiler carries and hands to clang at
flan run — so a green build is no evidence about that file. A trap1 call
merged clean into a tree where trap1 had grown a leading location pair,
and nothing said so until a program was compiled.

Also corrects this entry's own description of the session pins, which
still described the needles as they were before they were made to
discriminate.

FIX.org

@@ -2675,8 +2675,9 @@ this is available there at any price.
   ~flan_reload_call~, which is exactly the kind of sentence not to trust
   twice.
 - ~test_session.ml~: a slot added and a slot removed both accepted, the
-  module carrying ~flan_dyn_class_def~ and ~flan_reload_call~ and the packed
-  slot list, an unchanged class registering anyway, the refusal when a
+  module carrying a ~call~ to ~flan_dyn_class_def~, a definition of
+  ~flan_reload_call~ and the packed slot-list constant, an unchanged class
+  registering anyway with its own list, the refusal when a
   compiled caller is in the way, and the same edit accepted when the caller
   comes with it.
 
@@ -2687,3 +2688,31 @@ some time — the code is at the bottom of the same function — and the comment
 had simply not moved with it. Corrected rather than worked around; this
 lane's thunk goes through that path on every ~C-c C-c~ of a class, which is
 the default backend for ~flan dev~.
+
+A second one, found by the review rather than by the lane: two of the
+~test_session.ml~ pins above asserted the string ~flan_dyn_class_def~ against
+the module's IR text, and ~emit.ml~ writes a ~declare~ for every runtime
+entry point into every module it emits — so both passed against a module that
+registered nothing. They assert ~call void @flan_dyn_class_def~ and the packed
+slot-list constant now. Confirmed by mutation: with the thunk suppressed the
+old needles pass and the new ones fail. Worth carrying as a habit rather than
+as a fix — a needle that names a runtime symbol is matching the declare block
+unless it says ~call~.
+
+** What was run
+~dune test --root .~ green (exit 0, no FAIL lines) before and after the
+rebase onto dev-loop, and ~test_dev.exe~ run directly afterwards because its
+label can be swallowed by a cached run. ~dune build --root . @sanitize~ clean
+on the committed source, which is where the two-thousand-instance migration
+under collection actually gets looked at.
+
+The rebase is worth a line of its own. Three conflicts were additive —
+FIX.org, ~want_map~ (the diagnostics lane gave ~trap2~ a location pair, this
+one put a ~class_sync~ beside it, both wanted), and ~test_dev.ml~'s
+agent-socket block beside this one's. The fourth was not a conflict at all
+and is the one to remember: ~flan_dyn_class_def~'s argument check was written
+against the four-argument ~trap1~ and merged clean into a tree where ~trap1~
+takes a location first, so the class name would have been read as a length.
+*~dune build~ does not compile ~flan_dyn.c~* — it is a string the compiler
+carries and hands to clang at ~flan run~ — so a green build is not evidence
+about that file at all. ~dune test~ is, and so is running any program.