p2: digest with in-sift FIFO, SQLite caches, Honcho context, recover

Dixie is capped (max_inflight 2, queue_depth 8, queue_wait 20s) and
never queued on llama-server. Streaming chat, thinking off, 45s
fallback to clean. Digest and chunk-embedding caches are
content-addressed SQLite (Honcho context is not cached). Recover
uses the guarded Fetcher. guardian-star is refused in code.

vendor/modernc.org/libc/README.md

@@ -0,0 +1,50 @@
+# libc
+
+[![LiberaPay](https://liberapay.com/assets/widgets/donate.svg)](https://liberapay.com/jnml/donate)
+[![receives](https://img.shields.io/liberapay/receives/jnml.svg?logo=liberapay)](https://liberapay.com/jnml/donate)
+[![patrons](https://img.shields.io/liberapay/patrons/jnml.svg?logo=liberapay)](https://liberapay.com/jnml/donate)
+
+[![Go Reference](https://pkg.go.dev/badge/modernc.org/libc.svg)](https://pkg.go.dev/modernc.org/libc)
+
+Package libc is a partial reimplementation of C libc in pure Go.
+
+## ⚠ READ THIS BEFORE UPGRADING ⚠
+
+**This package is to ccgo what the `runtime` package is to Go.** It is not a
+library you happen to link against, it is the other half of the compiler. Code
+that ccgo produced and the libc it was produced for are one artifact split
+across two modules, and they are only ever tested as a pair.
+
+**The version numbers here do not mean what semver says they mean.** A release
+that bumps only the patch or the minor number can still change the contract
+between generated code and this package, which by semver's own rules it must
+not. Read every libc version as though it were a major one.
+
+None of this is new — it has been documented for as long as this package has
+carried ccgo's runtime, and it holds for every release. **What is new is how it
+fails.**
+
+Upgrading libc alone used to change behaviour quietly. It can now stop the
+build. The setjmp/longjmp support changed shape: `LongjmpRetval` went from an
+integer to a struct naming the jump buffer a longjmp targeted, because a region
+recovering that panic has no other way to tell whether the longjmp was meant for
+it or for a `setjmp` further out, and recovering one meant for another region
+resumes the program at the wrong place. Code generated by an older ccgo does not
+compile against it, failing on the conversion between `LongjmpRetval` and
+`int32`.
+
+That is the intended outcome rather than an oversight: a refusal to build, in
+place of a program that would have built and then jumped to the wrong `setjmp`.
+
+**It is a correctness fix, and there is no backward compatible way to make it.**
+Deciding which region a longjmp belongs to needs information the old panic value
+did not carry, so any fix has to change what that value is. Keeping the old
+shape working alongside the new one would leave every consumer silently on the
+broken path, which is the bug.
+
+The remedy is what it has always been, and it is **not** to pin an old libc and
+hope: recompile your C to Go with a ccgo new enough to depend on the libc you
+want, then use that pair together. If you consume translated code produced by
+someone else, `modernc.org/sqlite` for instance, take the libc version from that
+package's `go.mod` and do not bump it on your own just because a newer libc is
+tagged.