ci(traceability): the job container is where act_runner looks for node

The traceability job has been failing since it was written, and never on
anything it checks. It declared no `container:`, so it ran in the
runner's default image, which has no node; act_runner executes JS
actions with the node it finds inside the job container, and both
actions/checkout and upload-artifact are JS. The job died at
"Cannot find: node in PATH" before the repository was checked out, and
every later step then failed on an empty working tree -- the summary
step's "head: cannot open 'docs/traceability.md'" is that, not a missing
report.

node:20-bookworm, and the choice is not arbitrary: node is the part with
no workaround, while Debian 12 already carries python3.11 (tomllib, so
the stdlib-only extractor reads traceability.toml) and git (for the
pull_request diff step). Nothing in it names this repo, so the file
stays copyable into the other two components unedited, which its header
claims and this commit keeps true.

The kpnpp-builder and jellytau-builder images bake node in for exactly
this reason, and Dockerfile.builder-cpu says so in a comment. That
knowledge just had not reached the one job with no image of its own.

Second failure behind the first: the jray-project submodule was pinned
by SSH URL. The runner has no key, so `submodules: recursive` could not
have fetched the extractor even with node present. https, like the KPN
submodule beside it.

Gate and static check both pass locally on this tree -- 42/72 traced,
73.7% in CI scope, 0 orphans, 0 bare-cosine violations -- so what CI
reports next is a fact about CI, not about the tree.

.gitea/workflows/traceability-check.yml

@@ -7,7 +7,8 @@ name: Traceability Validation
 # prefixes count, which file suffixes are source, which directories to scan,
 # the threshold - lives in traceability.toml at the repo root, and the same
 # extractor is shared by all three JRay components. Copying this file into
-# another component needs no edits.
+# another component needs no edits - including the container image below, which
+# is a stock public one and names nothing about this repo.
 #
 # NOTE: the runner here is an Intel N100 with no discrete GPU. This job is only
 # ever static analysis of source comments plus markdown parsing, so it is cheap;
@@ -31,6 +32,20 @@ jobs:
     runs-on: linux/amd64
     name: Check requirement traces
 
+    # Gitea's act_runner executes JS actions - actions/checkout and
+    # upload-artifact are both JS - with the `node` binary found INSIDE the job
+    # container, not one it supplies. The runner's default image has none, so
+    # without this block the job dies at "Cannot find: node in PATH" before the
+    # repository is even checked out, and every later step fails on a missing
+    # working tree rather than on anything it was meant to check.
+    #
+    # node:20-bookworm rather than a Python image because node is the part that
+    # cannot be worked around: bookworm's python3 is 3.11, which has tomllib and
+    # is therefore already everything the stdlib-only extractor needs. Debian 12
+    # also carries the git the pull_request diff step below shells out to.
+    container:
+      image: node:20-bookworm
+
     steps:
       - name: Checkout repository
         uses: actions/checkout@v4

.gitmodules

@@ -4,4 +4,4 @@
 	branch = master
 [submodule "jray-project"]
 	path = scripts/vendor/jray-project
-	url = git@gitea.tourolle.paris:dtourolle/jray-project.git
+	url = https://gitea.tourolle.paris/dtourolle/jray-project.git