sl0p: add close_if_focused to LaunchOrFocusPlugin

Upstream's action focuses an already-running plugin, so a chord bound to it can
only ever open one -- there is no way to dismiss with the same key.

This cannot be fixed in a plugin. Keybindings are resolved into actions in
route.rs before a key reaches a pane, so the launching chord never arrives at
the plugin. intercept_key_presses does not help either: the intercept lives in
screen.rs and only sees keys that already became Action::Write, i.e. keys
destined for a pane. Confirmed empirically -- an intercepting build received
Ctrl-u but never Ctrl-;.

Closes only when the plugin is the focused pane in the client's ACTIVE tab, so
the chord cannot close whatever pane the user happens to be on. A plugin that
exists but is hidden behind a floating-layer toggle, or is focused in a
different tab, is revealed or brought over as before.

Defaults to false, so every existing binding is unaffected. Config-only, with no
protobuf representation: defaulted at both boundaries and dropped when an action
crosses the plugin API, so no prost regeneration is needed.

The 24 snapshot lines are the new field appearing in serialised keybind dumps.

1 files changed, 28 insertions, 0 deletions

diff --git a/README.md b/README.md
index 67239fec..13acfaae 100644
--- a/README.md
+++ b/README.md
@@ -317,6 +317,34 @@ without refreshing the `insta` snapshots. If you change anything about how frame
 pane titles render, expect to regenerate snapshots — and read the diffs before
 accepting them.
 
+### `close_if_focused` on `LaunchOrFocusPlugin`
+
+Makes one chord both open and dismiss a plugin:
+
+```kdl
+bind "Ctrl ;" {
+    LaunchOrFocusPlugin "file:~/.config/zellij/plugins/pane-finder.wasm" {
+        floating true
+        close_if_focused true
+    };
+}
+```
+
+Upstream's action focuses an already-running plugin, so the launch chord can only
+ever open it. A plugin cannot fix this itself: keybindings are resolved into
+actions in `route.rs` before a key can reach a pane, so the chord that launched a
+plugin never arrives at it — not even via `intercept_key_presses`, which only
+sees keys already destined for a pane.
+
+Closes only when the plugin is the **focused pane in the client's active tab**.
+Hidden behind a floating-layer toggle, or focused in another tab, it is revealed
+or brought over instead — so the chord can never close whatever pane you happen
+to be on.
+
+Defaults to `false`, so existing bindings behave exactly as before. It is a
+config-only option with no protobuf representation, and is dropped when an action
+crosses the plugin API.
+
 ## Bundled plugin: `sl0p/zj-pane-finder`
 
 A floating fuzzy finder for every pane in the session, filtering on pane