stabbur 0.11.0

A project can now run its models somewhere else.

Point a project at a server

If the models already live on another box, stabbur init used to have two answers and
both were wrong: download a copy you do not need, or bind nothing at all. There is a
third now.

stabbur init mybot --upstream http://gpu-box:8080/v1 --model some-model-it-serves

The wizard has an Upstream field for the same thing. Enter asks that server what it
serves and the model list becomes those ids — offering this machine's curated downloads
for a remote project would write a name the remote probably does not have, since the
two rarely match. The download total drops to the voices, which still run locally. An
unreachable box leaves the local list alone and says so rather than emptying the
screen.

Such a project is a few kilobytes rather than a dozen gigabytes. The manifest carries
upstream = "..." and stabbur chat, stabbur serve and stabbur doctor inside it
all use the remote, while the agent loop, tools, voices and browser UI stay here.

Two fixes that came with it

stabbur chat in a project now prefers that project's upstream over the machine-wide
chat_server, below an explicit --server. Without it a remote project tried to load
a local copy of a model it deliberately does not have.

stabbur serve read --upstream only from its own flag, so in a project whose
manifest declared one it resolved the locked model against the local library and
refused to start — while chat and doctor in the same directory used the remote
quite happily. It now honors a configured upstream (a project's, or
STABBUR_UPSTREAM).

If you are upgrading

Nothing changes for a project with local models. If you set STABBUR_UPSTREAM in your
environment, note that stabbur serve now respects it without --upstream — which is
what it always looked like it did.

uv tool upgrade stabbur