Context Circuit CLI 2.4.1

Context Circuit CLI 2.4.1

A patch for 2.4.0. The workspace schema stays at 3 and nothing is renumbered;
2.4.0 and 2.4.1 work in the same workspace.

The setup step that completes setup now makes the ID split itself. On a
workspace still at schema 2, the member band that gives the last member a
band, the member add --band that adds the last member, or the member use
that selects one, splits .context-circuit/ids.yaml into per-member files and
prints the split notice right after it succeeds. In 2.4.0 the split waited for
the next changing command and happened there without being asked for. A split
that setup step cannot make, such as one stopped by a member ID that is a
Windows device name, is a warning rather than a failure of the step, and the
next changing command refuses with the reason. The split is still idempotent,
and the one-person-first upgrade from 2.4.0 still holds: that person commits and
pushes the split, everyone else pulls before changing anything, and a conflict
in .context-circuit/ids/*.yaml from teammates who upgraded at the same time is
theirs to resolve by keeping the union of both sides.

The split notice names every shared file the command changed, worked out from
what actually changed: workspace.yaml, each ID file written or removed, and
members.yaml when the command changed it, which member band does. In 2.4.0
it always said workspace.yaml and .context-circuit/, leaving out the roster.

A refused record delete now shows its preview, with --confirm or without,
in YAML and --json: the records asked for with their author, path, and
status; blocked_by, each record outside the selection that still points at one
of them, with its author, path, status, and link, such as
belongs to intent i017; refused, the reason; and, for --id, add_ids, the
IDs to add. The reason is also printed on stderr, nothing is deleted or
released, and the exit status stays 1 so a script still sees the refusal. In
2.4.0 the refusal was an error alone, and a person had to run the command again
to see anything.

--workspace PATH and --json are accepted after the full command as well as
before it, for every command, so status --workspace PATH --json works like
--workspace PATH --json status, and member list --json works too. They still
do not go between a group and its subcommand. No command defines a flag of
either name. A
flag a command does not take is still named, and is now followed by that
command's signature, a line saying where the global flags may go, and the
help topic to read, with exit status 2, instead of an empty Usage of status:
block. --help after a command prints that command's help topic.

worktree prepare reports start, what the worktree actually started from:
--start as given, the base branch or origin/<base> it fell back to, or the
existing branch it checked out or resumed. base_branch keeps meaning this machine's base,
where the work is delivered, which a worktree started elsewhere need not share.
An explicit --start naming a local branch that is behind its remote-tracking
branch, or has diverged from it, is still used as asked, and sync_required
now says how many commits it is behind, and how many ahead when it has
diverged, says to remove the worktree and prepare again with
--start origin/<branch> or to bring the local branch up to date and rebase
the plan branch onto it, and names repo fetch. Preparation still never fetches, so the comparison is only as
recent as the last fetch, the way a stale derived base was already reported.

---

Built at commit 5b1530817a2deb1319745a95e2ea57dd1afcb609.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.