Self-hosted binary distribution and auto-update

Everlock 0.4 adds the machinery to distribute and self-update the native binary from everlock.sh itself — while keeping the project's hard rule that Everlock is always one self-contained binary with the model embedded, no assembly required.

What changed

Composed-asset serving. The site backend can now serve a large binary as an [[asset]] block in site.toml: an ordered list of git objects that are streamed and concatenated into a single response. The precomputed SHA-256 is exposed as an ETag / X-Everlock-SHA256 header, so a client can read it with a cheap HEAD request — no download unless the binary actually changed.
A split tool (everlock-split). Because an embedded-model binary is 256 MB to ~1.5 GB, committing one per release would be unmanageable. This post-build tool carves a finished binary into small code segments and stable 64 MB model chunks. git is content-addressed, so an unchanged model is stored once no matter how many versions reference it. The build stays untouched — the tool runs afterwards.
Automatic updates. The self-update job retrieves a new binary as well as applying a manually staged one. Once a day it checks its build's download URL, and only when the digest differs does it download, verify, stage the binary to a data-dir file, and apply it — keeping the previous binary as .old for rollback. It is on by default.
Deployment-aware graceful restart. When run under systemd socket activation, Everlock adopts the inherited sockets and restarts by draining in-flight requests and handing the socket back to systemd, so queued connections survive the swap. Standalone deployments keep the simple in-place restart. Either way, systemctl stop now drains cleanly instead of being cut off.

Why this matters

The download problem is really a storage problem: the same split that makes the binaries git-hostable also lets the homepage — which is itself an Everlock site — serve them without a separate release host or CDN. Auto-update runs code as the server, so trust rests on HTTPS and on you trusting everlock.sh (or a private mirror you point it at), with the SHA-256 as an integrity check. It is on by default.

Using it

Auto-update is on by default. Point it at a mirror with --update-url, or turn it off with --no-update (or EVERLOCK_UPDATE_ENABLED=false). The runtime toggle also lives in the new generic settings CLI — /settings set update.enabled false — recorded as an audited commit in the system store.

Direction

This release lands the mechanism end to end; publishing the official binaries through the cross-compile release pipeline, and a richer update status view, are the next steps. The full design and reasoning are written up in docs/self-update-distribution.md.