bring the repo up to org standards

Adopt the standard tooling: a Makefile of thin shims over a full
scripts-to-rule-them-all `script/` set, the canonical `.golangci.yml`
vendored byte-identical from `sneak/prompts`, docker-only linting via
`Dockerfile.lint`, a `Dockerfile` and Gitea workflow that gate every
push, and prettier/editorconfig/dockerignore config.

`make build` pointed at a `cmd/dcfinfo` that is not in the tree and
could never have succeeded; this repo is a library, so `build` is now
the compile check over every package.

Clear the 57 findings the canonical linter config reports on `pkg/dcf`.
Two were real: `findDCFMountPoints` checked a never-assigned `erro`
instead of the error from `findAllMountPoints`, discarding it, and
`privatePath` was computed twice so the first computation was dead.
Mountpoint selection otherwise behaves exactly as before; the defects
that survive are filed as issue #6, not fixed here.

Rename `DCFStore` to `Store` and `DCFObject` to `Object` (with its
`DCFStoreRoot` field to `StoreRoot`), which revive's stutter rule
requires and which the `fs.FS` rework in issue #4 will build on.

Replace the placeholder test with tests over the exported surface.
The filesystem walk stays uncovered: it is reachable only through
`GetDCFStores`, which needs real mounted media.

README keeps its content, reorganised into the required sections and
gaining Entrypoints.

(closes #1)

script/lint

@@ -0,0 +1,71 @@
+#!/bin/sh
+# script/lint: run the linter. golangci-lint is never installed locally: it
+# runs via docker only, one way, everywhere.
+#
+# Traps, each of which yields a green run over an unlinted or partly linted
+# tree:
+#
+# 1. A bare `docker build -f Dockerfile.lint .` serves the lint layer from
+#    cache on an unchanged tree and exits 0 having linted nothing, and
+#    BuildKit ignores a --no-cache-filter whose stage name matches
+#    nothing, restoring that no-op after a rename. So the run is not
+#    trusted: script/assert-step-ran requires the log to show the lint
+#    step executing and golangci-lint's own success line coming out of
+#    it. A cached or absent step fails that.
+#
+# 2. .dockerignore decides what reaches the container, and only what
+#    reaches it is linted, so excluding a Go file drops it from the lint
+#    with the linter still reporting `0 issues.` over what it was
+#    handed. So the context is not trusted either: the lint stage
+#    inventories the sources that reached it, and
+#    script/assert-context-complete compares that against the git index,
+#    which .dockerignore cannot touch. Never exclude Go sources,
+#    go.mod/go.sum or .golangci.yml — and now nothing silently does.
+set -eu
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd -P)"
+ROOT="$(cd "$SCRIPT_DIR/.." && pwd -P)"
+
+dockerfile=Dockerfile.lint
+
+# Must match the stage name in Dockerfile.lint.
+stage=lint
+
+main() {
+    cd "$ROOT"
+
+    tmp="$(mktemp -d "${TMPDIR:-/tmp}/$("$SCRIPT_DIR/projectname")-lint.XXXXXX")"
+    trap 'rm -rf "$tmp"' EXIT INT TERM
+
+    # No --target: whatever stage is last is the one BuildKit builds, and
+    # the assertion below is what decides whether the linter was in it.
+    # --progress=plain is load-bearing — the tty renderer discards all but
+    # the tail of a step's output. The exit status travels through a file
+    # because a pipeline's status is the last command's; `set +e` is what
+    # lets the recording line run at all, since errexit would otherwise
+    # abandon the subshell on a failing build. A missing file reads as
+    # failure.
+    (
+        set +e
+        docker build \
+            --progress=plain \
+            --no-cache-filter="$stage" \
+            --output=type=cacheonly \
+            -f "$dockerfile" . 2>&1
+        echo "$?" >"$tmp/status"
+    ) | tee "$tmp/build.log"
+
+    status="$(cat "$tmp/status" 2>/dev/null || echo 1)"
+    [ "${status:-1}" -eq 0 ] || exit "${status:-1}"
+
+    script/assert-step-ran "$tmp/build.log" "$stage" \
+        '^RUN golangci-lint run' '^0 issues[.]$' 'the linter'
+
+    # That the linter ran says nothing about what it was given. The
+    # expectation comes from git and the evidence from the build, which
+    # is the only reason comparing them means anything.
+    script/repo-source-manifest >"$tmp/expected"
+    script/assert-context-complete "$tmp/build.log" "$stage" "$tmp/expected"
+}
+
+main "$@"