Let the image build see the dependency Cargo patches

The rename pass vendored a patched sieve-rs and pointed Cargo.toml's
[patch.crates-io] at vendor/sieve-rs. .dockerignore ignores everything and
re-includes a short list that did not have vendor on it, so the image build
had no such directory and stopped at

    failed to load source for dependency `sieve-rs`
    failed to read /build/vendor/sieve-rs/Cargo.toml

CI could not have caught that: it builds from a checkout, where the
directory is simply there, and only the image build has a context to prune.
The first that was known about it was a tag that had already been pushed.

So: vendor is re-included, and tools/fork/context-check.py now asserts the
thing that was quietly assumed -- every path a [patch] section names exists
and survives .dockerignore. It runs beside the other fork checks and takes
no toolchain.

Also, the comments in .dockerignore started with // , which Docker does not
read as a comment: they were patterns that happened to match nothing. They
are # now.

.gitea/workflows/ci.yml

@@ -35,6 +35,11 @@ jobs:
       - run: python3 tools/fork/name-check.py
       - if: always()
         run: python3 tools/fork/notice-check.py
+      # Cargo can patch a dependency to a directory in this repository, and
+      # the image builds from a context .dockerignore prunes to almost
+      # nothing. CI never sees the difference; a release does.
+      - if: always()
+        run: python3 tools/fork/context-check.py
 
   build:
     # Either runner (host1 or host2): the build needs no docker socket.