docs(cli): ws rm on a workspace a window is showing brings it back

tty7 ws rm 0c4c9162   # exits 0, says nothing
    tty7 ls               # 0c4c9162 is still there

Both are correct and together they read as a failed delete. The GUI logs
what it did — "deleted on its machine while a window still had it open;
putting it back under the same id" — rather than leave a window pointing
at nothing. The panes really are gone; what returns is empty, with a
fresh shell and a new name, which is why the codename changed under an
unchanged id.

Nothing said so on the side the reader typed. `ws rm`'s help now does,
including that a workspace with no window on it simply goes.

Measured twice against a live GUI: rc 0, panes to zero, no orphans, the
same id back with a different name, and the GUI still running.

The reconciliation itself is sound and was what I set out to test: a
workspace deleted underneath an open window produces no warning and no
error, and leaves the tree and the pane registry agreeing.

crates/tty7-cli/src/cli.rs

@@ -440,7 +440,17 @@ pub enum WsCmd {
         ws: String,
     },
 
-    #[command(about = "Delete the workspace and hang up its panes")]
+    #[command(
+        about = "Delete the workspace and hang up its panes",
+        long_about = "Delete the workspace and hang up its panes.\n\n\
+                      A window still showing it does not close: the GUI puts the workspace \
+                      back under the same id rather than leave a window pointing at \
+                      nothing. The panes are gone either way — that part is not undone — \
+                      and what returns is empty, with a fresh shell and a new name. So \
+                      `tty7 ws rm X && tty7 ls` can still list X, and that is the window's \
+                      doing, not a failed delete.\n\n\
+                      With no window on it, the workspace simply goes."
+    )]
     Rm {
         #[arg(value_name = "WORKSPACE")]
         ws: String,