Rename the CLI package to tsunagi and its executable to tsng

The command line package is now `tsunagi` and builds the `tsng` executable,
which the packages, the unit, the installers and the workflows install and
run. The core library package becomes `tsunagi-core`, keeping the library name
`tsunagi`, so no code changes `use tsunagi::...`. Directories follow
(crates/tsunagi-core, crates/tsunagi). Every command shown to a person is now
`tsng ...`.

Co-Authored-By: Claude <noreply@anthropic.com>

dist/linux/README.md

@@ -27,27 +27,27 @@ group, so after `sudo usermod -aG tsunagi "$USER"` (and logging in again) no
 `sudo` is needed:
 
 ```sh
-sudo tsunagi status
-sudo tsunagi join <network-name> <tsn1…secret>
+sudo tsng status
+sudo tsng join <network-name> <tsn1…secret>
 ```
 
 ## As your own user — one capability, no service
 
 ```sh
-sudo install -m 0755 tsunagi /usr/local/bin/tsunagi
-sudo setcap cap_net_admin,cap_net_bind_service+p /usr/local/bin/tsunagi
+sudo install -m 0755 tsunagi /usr/local/bin/tsng
+sudo setcap cap_net_admin,cap_net_bind_service+p /usr/local/bin/tsng
 sudo usermod -aG tsunagi "$USER"   # so the resolver works; log in again after
-tsunagi up
+tsng up
 ```
 
 Nothing runs as root. The capability is lost on every rebuild or copy of the
 binary, so re-run `setcap` after replacing it. The agent uses your per-user
-state directory and socket, so plain `tsunagi status` (no sudo) reaches it.
+state directory and socket, so plain `tsng status` (no sudo) reaches it.
 
 ## Without touching the OS
 
 ```sh
-tsunagi up --no-tun
+tsng up --no-tun
 ```
 
 Tunnels form and handshake between agents, but no interface, address or route is