Pin the security policy's evidence that the core is written to the commit it was read at

SECURITY.md

@@ -72,17 +72,37 @@ THIS PARAGRAPH NAMED NEITHER THE CRATE NOR THE SUITE, AND THE ONE AFTER IT SAID
 THE CORE WAS NOT WRITTEN. Both were true when they were written and had stopped
 being true. A reporter who believed either would not have opened the code,
 because the file told them there was none. Read at
-`5d67a074202de4d8069eee55d44812bf7fa9e201`:
+`5d67a074202de4d8069eee55d44812bf7fa9e201`, and each command names that commit so
+that running it returns what is beside it:
 
-    git rev-parse origin/main
-    5d67a074202de4d8069eee55d44812bf7fa9e201
-    git ls-tree -r --name-only origin/main | grep -c '^src/'
+    git ls-tree -r --name-only 5d67a074202de4d8069eee55d44812bf7fa9e201 | grep -c '^src/'
     10
-    git ls-tree -r --name-only origin/main | grep -c '^tests/'
+    git ls-tree -r --name-only 5d67a074202de4d8069eee55d44812bf7fa9e201 | grep -c '^tests/'
     6
     gh api repos/Flowfin/core --jq .language
     Rust
 
+What the two counts answer today is a different question from what this
+paragraph is evidence for, and it is asked without a number beside it:
+
+    git ls-tree -r --name-only origin/main | grep -c '^src/'
+    git ls-tree -r --name-only origin/main | grep -c '^tests/'
+
+THE THREE COMMANDS THAT READ THE TREE ASKED `origin/main` UNTIL THIS EDIT, AND
+THE OUTPUTS UNDER THEM WERE A READING AT THE COMMIT NAMED ABOVE THEM. The
+reference moves and the reading does not, so the block agreed with itself on the
+day it was written and on no day after it: at
+`53cd6994d93ff76982301f52908759a555fe793b` the two counts answer forty-six and
+sixty-eight, against the ten and the six pasted here. A reporter sizing the
+surface from those numbers was reading a fraction of it, which is this
+paragraph's own subject - a reader who believed a stale sentence and did not open
+the code. The fourth command is unmoved and keeps its output: it asks the hosting
+provider rather than a reference in this tree. The numbers are pinned rather than
+refreshed, because a fresh reading under a moving reference is this same defect
+one merge later, and a `git rev-parse origin/main` whose output named the commit
+is gone rather than pinned, since a command pinned to a commit already says which
+one it is. It was found by running the three lines as they were written.
+
 The inventory above is a list, and a list drifts, which is what happened. The
 count beside it always said to derive it and still does: