feat(cli): colitur publish -- the static tree

Writes ef/<year>.{json,csv,xml,ics}, one JSON per day, the schema and a
generated index. That tree is the API: any web server or git repo serves
it, and nothing runs at request time.

Deterministic: publishing twice is byte-identical, asserted in cli.t.
That is what makes publishing into a git repo safe -- the diff shows
only real change, and you review it before pushing.

Non-destructive: a manifest records exactly the files this tool wrote,
so --prune can only remove files a previous run created. A file you put
in the output directory yourself is never touched, with or without
--prune. Asserted in both directions.

Pruning a stale file also removes any directory it leaves empty behind
it (e.g. an old year's own ef/<year>/ tree), stopping at --out itself --
without this, a pruned year's own directory would survive empty and
test -d would still see it.

schema/day-v1.json is resolved the same prefix-relative way data/ef's
own sexp files are (installed vs build-tree, probed rather than
assumed), never from cwd, and a missing schema fails with one line on
stderr before anything is written rather than emitting an empty file.
Needed schema/day-v1.json wired into the root dune file's default alias
and into test/dune's cram deps -- unlike data/ and templates/, nothing
made dune mirror schema/ into the build tree before this.

unix is added to bin/dune's libraries for mkdir_p; it ships with the
compiler, so colitur.opam and dune-project are unchanged.

1 files changed, 13 insertions, 1 deletions

diff --git a/dune b/dune
index b7cd19b..e2353df 100644
--- a/dune
+++ b/dune
@@ -23,10 +23,22 @@
 ; this file was originally written to close applied to it too -- a fresh
 ; `dune build` left it absent from _build/default/data/ef/, only ever
 ; materialised there as a side effect of test/dune's own deps.
+;
+; schema/day-v1.json added here for the identical reason again (Task 12,
+; `colitur publish`): unlike data/ef/, the top-level schema/ directory has
+; no dune file of its own, so nothing makes dune copy it into
+; _build/default/ by default -- confirmed empirically, a clean `dune build`
+; left _build/default/schema/ missing entirely. bin/main.ml's own
+; [schema_path] resolves it the same prefix-relative way [data_dir] resolves
+; the sanctoral data, and that resolution needs the file actually present in
+; the build tree, not only in the source tree. This is a BUILD-TIME
+; convenience only -- it says nothing about `dune install`, which is
+; Task 13's own job (see schema_path's comment in bin/main.ml).
 (alias
  (name default)
  (deps
   (alias_rec install)
   data/ef/sanctoral.sexp
   data/ef/adjustments.sexp
-  data/ef/lectionary.sexp))
+  data/ef/lectionary.sexp
+  schema/day-v1.json))