Make the memory check a gate

It was reporting and shrugging. A definite leak, a read past the end of an
allocation or a branch on uninitialised memory now fails the build on the
push that introduces it, which is the only point at which it is cheap to
fix.

The six findings the job had on its first run were fixed rather than
excused, so the gate closes on a clean tree instead of on a backlog.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Andrew Kesterson <andrew@aklabs.net>

.gitea/workflows/ci.yaml

@@ -132,14 +132,13 @@ jobs:
   # suites scale themselves down when they detect valgrind, which turns them
   # into the broadest path coverage in the tree at a cost this job can afford.
   #
-  # continue-on-error until TODO.md "Memory checking" items 34-39 are closed.
-  # The findings are real and they are all in libakgl, so this job is red today
-  # by telling the truth; gating on it now would only teach everyone to ignore a
-  # red build. Remove the flag with the commit that closes the last item -- and
-  # the JSON one (item 34) is four lines, so that should not be a long wait.
+  # This job gates. A definite leak, a read past the end of an allocation, or a
+  # branch on uninitialised memory fails the build on the push that introduced
+  # it -- not on the day somebody gets around to caring. The six findings this
+  # job had on its first run were fixed to make that possible rather than
+  # excused into a warning.
   memory_check:
     runs-on: ubuntu-latest
-    continue-on-error: true
     steps:
       - name: Check out repository code
         uses: actions/checkout@v4