feat(acp): let an agent opt into the latest adapter release

New models ship inside an adapter's bundled runtime, so a pinned adapter can
trail what the vendor already serves: claude-fable-5-1 is live, but through
the pinned claude-agent-acp (whose SDK bundles Claude Code 2.1.232) every
request answers "API Error: 400 Claude Code 2.1.232 does not support this
model; version 2.1.251 or newer is required." The model cannot appear in
codeg until the pin moves. A user who accepts the risk should be able to
follow the newest release themselves, per agent, without waiting.

"Adapter version" is a per-agent control in Agent Settings, npx agents only
(a binary or uvx install has no npm dist-tag to track). It rides the same
`env_json` store as pi's runtime override and the host-tools knob — a
`CODEG_ADAPTER_CHANNEL=latest` reserved key, edited into the env draft and
persisted by the same Save button — so both runtimes and both readers resolve
it through layers that already exist. Pinned stays the default and is labeled
recommended; the copy under the control says plainly that new releases are
unreviewed and can break the agent, and that the newest release is
occasionally known broken (Kimi Code 0.37.x took every session down while it
was the newest).

The channel is consulted at install and upgrade time only. On `latest` the
prepare path tries `<package>@latest` first, with the same npm flags every
agent install already gets (`--include=optional` for platform optional deps,
`--registry` past lagging mirrors); if that fails — npm unreachable, a mirror
not yet carrying the tag's target — it says so in the install log and retries
the reviewed pinned spec, so the agent still installs rather than not at all.
A launch never consults npm: it runs whatever is installed, and nothing polls
in the background. The recorded installed version keeps coming from the real
post-install probe, so Version Status reports what actually landed, never
what was asked for — and on the latest channel the pass state keeps the
Upgrade action available, because the compare-to-pin flow cannot know whether
npm has something newer.

An explicit Custom install version wins on either channel and never falls
back: the user asked for that exact version, and quietly installing a
different one would relabel their choice.