REPO_POLICIES: fix the second review's findings on the compaction (#158)

Fixes the seven findings of
#159 (comment), with
the wording each one gives.

- Go key points: "whatever files the mount holds".
- `.dockerignore`: "Such a `.dockerignore` is more dangerous than a
  short file with no secret patterns at all".
- Python: "pipenv checked the hashes of the lockfile's packages".
- Python: "In that step" leads only the two bullets about that step.
  The other four sit under "A Python repository's `script/bootstrap`:".
- Entrypoints: "Three more scripts have no required target:".
- Dockerfile: the two ways a stage installs what its image lacks are
  bulleted again, as on `next`.
- Version: the sentence ends at "stage-scoped", then "It has no
  default."
- `TODO.md`: the entry carries the new size, 1,066 lines and 7,812
  words.

Model: fable-5-1

prompts/REPO_POLICIES.md

@@ -103,7 +103,7 @@ where its implementation lives:
 - `make docker`: `script/docker`
 - `make hooks`: `script/install-precommit` installs the git pre-commit hook.
 
-Three more scripts have no target:
+Three more scripts have no required target:
 
 - `script/precommit` is what the pre-commit hook runs. It calls `script/check`.
   Repo-type-specific extras belong in it, not in the hook itself; `go mod tidy`
@@ -328,9 +328,10 @@ docker build --build-arg CACHEBUST="$(date +%s)-$$" \
 What each stage installs:
 
 - The gate phases and the build stage start from their pinned base images. They
-  install what those images lack inline, as the canonical Go `Dockerfile` below
-  does for `git`. Or they run `script/bootstrap`, as the `prompts` repo's own
-  `Dockerfile` does for its yarn packages.
+  install what those images lack in either of these ways:
+    - inline, as the canonical Go `Dockerfile` below does for `git`
+    - by running `script/bootstrap`, as the `prompts` repo's own `Dockerfile`
+      does for its yarn packages
 - The development environment stage installs development prerequisites by
   running `script/bootstrap`. Only system packages may be installed inline above
   it, so that check builds keep them; the `prompts` repo's own `Dockerfile` does
@@ -498,9 +499,9 @@ Key points:
         - the linters and their settings in `.golangci.yml`
         - the golangci-lint version
 - The modules are kept in a layer rather than a cache mount. A cache mount is
-  shared by every build on the host, and Go builds from whatever files it holds
-  without checking them again (only `go mod verify` does). A file changed there
-  would go unnoticed.
+  shared by every build on the host, and Go builds from whatever files the mount
+  holds without checking them again (only `go mod verify` does). A file changed
+  there would go unnoticed.
 - The test command keeps the first run's output, to look in it for what Go
   prints for a hang. `panic: test timed out` means the test's own timer fired.
   `*** Test killed` means `go test` stopped a test that ignored that timer,
@@ -567,6 +568,9 @@ In that step, `script/bootstrap`:
 
 - installs no Python: the tests use the distribution's Python, which a step
   above it installs.
+
+A Python repository's `script/bootstrap`:
+
 - puts pipenv in a virtual environment at `$HOME/.pipenv`, because Debian's
   Python refuses a system-wide `pip install`. It creates the environment with
   `python3 -m venv` when it is missing, then uses that environment's `pip` and
@@ -592,12 +596,12 @@ In that step, `script/bootstrap`:
 when the distribution's Python differs from it.
 
 A kept layer holds nothing a new install would refuse. pip checked the hashes of
-pipenv and its dependencies, and pipenv those of the lockfile's packages. pipenv
-creates its virtual environment with the `virtualenv` package. The packages that
-`virtualenv` adds come from wheels inside it, so the hash pip checked for it
-covers them. System packages, Python among them, are not fixed by a hash. They
-keep the versions the package manager gave when the layer was built; a new
-install may get newer ones.
+pipenv and its dependencies, and pipenv checked the hashes of the lockfile's
+packages. pipenv creates its virtual environment with the `virtualenv` package.
+The packages that `virtualenv` adds come from wheels inside it, so the hash pip
+checked for it covers them. System packages, Python among them, are not fixed by
+a hash. They keep the versions the package manager gave when the layer was
+built; a new install may get newer ones.
 
 As with Go's modules, the packages are kept in a layer, not a cache mount, which
 every build on the host shares and nothing checks again.
@@ -677,7 +681,7 @@ canonical Go `Dockerfile` above shows:
 
 - It takes the version from the `VERSION` build argument when one is given,
   otherwise from `git describe`. `ARG VERSION` is declared in that stage,
-  because `ARG` is stage-scoped, and has no default.
+  because `ARG` is stage-scoped. It has no default.
 - It has `git`: the Debian Go image has it, and an alpine one needs
   `apk add --no-cache git`.
 - It marks its working directory safe for git
@@ -802,9 +806,9 @@ a pattern without a leading `**/` is anchored at the build-context root.
 
 - A `.dockerignore` listing `.env`, `*.pem` and `*.key` therefore excludes only
   the copies at the repository root. `config/.env` and `certs/server.key` still
-  reach the context and can land in an image layer. That is worse than a file
-  with no secret patterns at all, because it reads as solved and stops anyone
-  looking.
+  reach the context and can land in an image layer. Such a `.dockerignore` is
+  more dangerous than a short file with no secret patterns at all, because it
+  reads as solved and stops anyone looking.
 - Give every depth-independent pattern the `**/` prefix, and leave only
   genuinely root-anchored entries unprefixed. Those are `.claude`, `.yarn/*`,
   `!.yarn/releases`, and the repo's own host-built binary. The binary is written