build: ship the sl0ppi CLI in the tarball

The artifact was stale twice over: it predated the protobuf fix and did not
contain the CLI at all. Both fixed, and the whole chain re-verified from the
tarball rather than assumed.

The CLI ships as a single 31K file (`bun build --target=bun`) run by the bundled
bun, rather than a source tree or a second `--compile`d binary that would embed
another 90M copy of bun. `install.sh` generates the wrapper and pins
SL0PPI_BIN to the sl0ppij it just installed, so the orchestrator can never end
up driving some other zellij that happens to come first on PATH.

Verified in a throwaway HOME with node, npm, bun, cargo, rustc and python3 all
replaced by poison stubs that fail loudly if invoked:

  sl0ppij --version   -> 0.45.0+sl0p1        (static musl, no libc dependency)
  pi --version        -> 0.84.1              (bundled bun)
  sl0ppi doctor       -> all good
  sl0ppi init x2      -> two projects scaffolded
  sl0ppi up           -> session "dev", 2 tabs, agents suspended
  sl0ppi ls           -> agent:suspended, 1 pane each
  sl0ppi up (again)   -> "up to date"

And the promise the whole thing exists for, end to end: attach a client, press
Enter in the suspended agent pane, and pi starts on the bundled runtime -- while
the other project's agent stays suspended, because only the focused pane got the
key.

`make test` now runs the CLI suite alongside the Rust ones, so the two halves
cannot drift apart unnoticed.

1 files changed, 3 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index 0c5dd6d..80f44d4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -20,3 +20,6 @@
 .DS_Store
 
 # the fork's own ignores are kept inside sl0ppij/.gitignore
+
+# CLI bundle (a build output of `make cli`)
+/cli/dist/