Give every API value with a unit as a number (closes #199)

A value with a unit is now a number, and its field name ends in the
unit, as the vendored API_POLICIES.md requires. @meta.execution_time
becomes execution_time_ms. In the stats answers, uptime,
connection_duration, memory_usage and whois_stats.current_interval
become uptime_seconds, connection_duration_seconds, memory_usage_bytes
and whois_stats.current_interval_seconds. connection_duration_seconds
is null while the feed is not connected. The status page formats the
numbers itself. REPO_POLICIES.md is re-vendored from the same
sneak/prompts commit.

Model: opus-5-5

REPO_POLICIES.md

@@ -1,6 +1,6 @@
 ---
 title: Repository Policies
-last_modified: 2026-10-18
+last_modified: 2026-10-27
 ---
 
 This document covers repository structure, tooling, and workflow standards. Code
@@ -12,6 +12,7 @@ style conventions are in separate documents:
 - [JavaScript](https://git.eeqj.de/sneak/prompts/raw/branch/main/prompts/CODE_STYLEGUIDE_JS.md)
 - [Python](https://git.eeqj.de/sneak/prompts/raw/branch/main/prompts/CODE_STYLEGUIDE_PYTHON.md)
 - [Go HTTP Server Conventions](https://git.eeqj.de/sneak/prompts/raw/branch/main/prompts/GO_HTTP_SERVER_CONVENTIONS.md)
+- [API Policies](https://git.eeqj.de/sneak/prompts/raw/branch/main/prompts/API_POLICIES.md)
 
 ---
 
@@ -174,27 +175,32 @@ style conventions are in separate documents:
   `script/cibuild`. `script/lint`, `script/test`, `script/cibuild` and
   `script/docker` are the four, and there is no fifth — `script/check` runs the
   two gate phases and `script/fmt-check`, and builds no image of its own. In
-  every stage of the `Dockerfile`, `ARG CACHEBUST` comes right after the steps
-  that install system packages and download Go's modules, or right after `FROM`
-  in a stage with neither, and every step that lints, tests or compiles comes
-  after it. A step that installs anything else as well, such as a
-  `script/bootstrap` that also installs node packages, comes after it too. A new
-  value reruns every `RUN` step after that line; `COPY` steps are compared by
-  content and need nothing. Docker keeps the layers above the line until the
-  base image, their own lines or the files they copy change. A stage without the
-  `ARG` line is served from cache on an unchanged tree, so a repository
-  re-vendors the scripts and adds the `ARG` lines in one commit. The scripts do
-  not pass `--no-cache`: it reruns every step too, but it also builds the layers
-  above the line again and empties every cache mount, so Go's build cache and
-  golangci-lint's, which the canonical Go `Dockerfile` below mounts so that they
-  survive between check builds, would start empty every time. A bare
-  `docker build .` is not evidence that anything ran: a sub-second build
-  reporting success is a cache hit, not a result. Never invalidate by pruning —
-  `docker builder prune` and friends destroy a build cache shared with every
-  other build on the host. When a check is added or changed, prove it works by
-  planting a defect it must catch and watching the run fail on it, then revert
-  the defect. A green run alone shows neither that the check ran nor that it
-  covers what it should.
+  every stage of the `Dockerfile`, every step that lints, tests or compiles
+  comes after `ARG CACHEBUST`. `ARG CACHEBUST` comes right after these steps:
+    - the steps that install system packages
+    - the steps that download Go's modules
+    - the step that runs `script/bootstrap` to install a Python `test` phase's
+      packages from `Pipfile.lock`
+
+    A stage with none of these steps declares `ARG CACHEBUST` right after
+    `FROM`. A step that installs anything else as well, such as a
+    `script/bootstrap` that also installs node packages, comes after it too. A
+    new value reruns every `RUN` step after that line; `COPY` steps are compared
+    by content and need nothing. Docker keeps the layers above the line until
+    the base image, their own lines or the files they copy change. A stage
+    without the `ARG` line is served from cache on an unchanged tree, so a
+    repository re-vendors the scripts and adds the `ARG` lines in one commit.
+    The scripts do not pass `--no-cache`: it reruns every step too, but it also
+    builds the layers above the line again and empties every cache mount, so
+    Go's build cache and golangci-lint's, which the canonical Go `Dockerfile`
+    below mounts so that they survive between check builds, would start empty
+    every time. A bare `docker build .` is not evidence that anything ran: a
+    sub-second build reporting success is a cache hit, not a result. Never
+    invalidate by pruning — `docker builder prune` and friends destroy a build
+    cache shared with every other build on the host. When a check is added or
+    changed, prove it works by planting a defect it must catch and watching the
+    run fail on it, then revert the defect. A green run alone shows neither that
+    the check ran nor that it covers what it should.
 
 - **The gate phases are separate stages, and the build stage depends on both.**
   The lint phase is based on the `golangci/golangci-lint` image (pinned by
@@ -309,6 +315,9 @@ style conventions are in separate documents:
           a package's findings only when the package's files and those of every
           package it imports, `go.mod`, the linters and their settings in
           `.golangci.yml`, and the golangci-lint version are all unchanged.
+        - In a Python `test` phase, the layer of the step that runs
+          `script/bootstrap` to install the packages from `Pipfile.lock`, as
+          described for that phase below.
     - If the project uses `//go:embed` directives that reference build artifacts
       (e.g. a web frontend compiled in a separate stage), the lint phase must
       create placeholder files so the embed directives resolve. Example:
@@ -363,6 +372,67 @@ style conventions are in separate documents:
       `--build-arg VERSION=...`, as `script/docker` and `script/cibuild` already
       do.
 
+- **A Python `test` phase that installs its packages from `Pipfile.lock` does it
+  above `ARG CACHEBUST`, so check builds keep them.** The steps are
+  `COPY script/ script/`, `COPY Pipfile Pipfile.lock ./` and
+  `RUN script/bootstrap`, with `ARG CACHEBUST` right after them. Docker keeps
+  what that `RUN` installed until the base image, `script/`, `Pipfile`,
+  `Pipfile.lock` or a line up to and including the `RUN` changes. The tests run
+  after `ARG CACHEBUST`, on every check build. In every other stage, a step that
+  installs Python packages comes after `ARG CACHEBUST`.
+    - When `script/bootstrap` runs in that step, it installs nothing beyond
+      system packages, pipenv and its dependencies, and the packages from
+      `Pipfile.lock`. It installs no Python there: the tests use the base
+      image's Python, which the image's hash pins. If it installs anything else
+      there, the step goes after `ARG CACHEBUST`.
+    - Every external reference must be pinned by hash, so `script/bootstrap`
+      installs pipenv and its dependencies by hash. It does so with
+      `pip install --require-hashes -r` and a requirements file in `script/`
+      that lists each of them with `==` and its `--hash`. pip refuses to install
+      a dependency the file does not list.
+    - It then runs `pipenv install --deploy`, with `--dev` when the tests need
+      the development packages. `--deploy` installs only what `Pipfile.lock`
+      names, checks every package against the lockfile's hashes, and fails when
+      the lockfile is out of date with `Pipfile`.
+    - A kept layer holds nothing a new install would refuse: pip checked pipenv
+      and its dependencies, and pipenv checked the lockfile's packages, against
+      their hashes. pipenv creates its virtual environment with the `virtualenv`
+      package. The packages that `virtualenv` adds come from wheels inside that
+      package, so the hash pip checked for it covers them. Two things in the
+      layer are not fixed by a hash. A package with no ready-built wheel for the
+      image is built from source. pip downloads the build tools without a hash
+      check, so a kept layer's build of such a package may differ from a new
+      one. And system packages 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.
+      A cache mount is shared by every build on the host, and nothing checks its
+      files again.
+
+    In this example, `script/bootstrap` finds `make` and `git` already
+    installed, installs pipenv and its dependencies by hash, and runs
+    `pipenv install --dev --deploy`:
+
+    ```dockerfile
+    # Test phase. The 90-second timeout covers both pytest runs.
+    # python:3.x-slim, YYYY-MM-DD
+    FROM python@sha256:... AS test
+    # make and git are base tools that script/bootstrap installs when they
+    # are missing. Installed here, they stay in their own layer when
+    # script/ changes.
+    RUN apt-get update \
+        && apt-get install -y --no-install-recommends make git \
+        && rm -rf /var/lib/apt/lists/*
+    WORKDIR /app
+    COPY script/ script/
+    COPY Pipfile Pipfile.lock ./
+    RUN script/bootstrap
+    ARG CACHEBUST
+    COPY . .
+    RUN timeout 90 sh -c 'pipenv run pytest || { \
+            echo "--- Rerunning with -v for details ---"; \
+            pipenv run pytest -v; exit 1; }'
+    ```
+
 - Every repo should have a Gitea Actions workflow (`.gitea/workflows/`) that
   runs `script/cibuild` on push, and checks out the repo as its only other step,
   with `persist-credentials: false`: `script/cibuild` needs no token, and