install/argsh.pin points at an unmerged argsh branch (feat/process-trace-phase2)

[fentas]

The published installer docs/public/lo-up bundles an argsh runtime built from
a7b0295e62c708d7fe237252f8422576233cc8fa, recorded in install/argsh.pin by #139.
That commit is on argsh's feat/process-trace-phase2 branch, not on main.

Why it matters

The loup-bundle CI job checks argsh out at the pin. If that branch is
force-pushed, rebased or deleted in arg-sh/argsh, the commit becomes
unreachable and the job fails at actions/checkout with "could not find the
ref" — before it builds anything, and with no mention of this pin in the error.

The published installer also ships a runtime from an unmerged feature branch to
every curl … | sh user, which is a supply-chain fact worth being deliberate
about rather than inheriting from whoever last ran install/build.

What to do

Move the pin to a reachable, merged argsh revision (main, or a tag) once the
lo-up bundle builds byte-exact against it:

git -C /path/to/arg-sh/argsh checkout <merged-ref>
ARGSH_PIN_UPDATE=1 ARGSH_SRC=/path/to/arg-sh/argsh ./install/build

Commit install/argsh.pin and docs/public/lo-up together — a bats gate
compares the pin against the runtime baked into the bundle.

Watch for a behaviour delta: the phase-2 process-trace work is why the pin is
where it is, so a move to main may change what the bundled runtime does.

The risk is written in install/argsh.pin and install/README.md so whoever
hits the CI failure finds the cause; this issue is the fix.