sl0p: the plugins we ship do not ask for permission

pane-finder requests three permissions as it loads, so the first press of a
keybinding we ship opened a consent screen instead of a fuzzy finder. Prompting
is right for a wasm you found on the internet and wrong for the ones that come
in our own tarball.

plugin_is_shipped_with_sl0ppi (zellij-utils/src/input/permission.rs) grants
those implicitly, through the same instruction a human "y" produces, so the
plugin's permissions are set and recorded exactly as before. "Ours" is narrow
on purpose:

- builtins, asked via the existing PluginConfig::is_builtin -- the same
  predicate check_command_permission already uses to exempt them, so the two
  cannot drift;
- files inside a plugin directory we install into: the config dir's plugins/
  and the data dir's plugins/;
- nothing else. Remote plugins are never trusted, paths are normalised
  lexically first so plugins/../../evil.wasm is not "inside" the dir, and the
  directories are derived from the environment and default locations -- so
  getting them wrong costs a prompt and can never grant one elsewhere.

The trade, documented in config/README.md: <config dir>/plugins/ is now a
trusted directory. Anything able to write there can already bind arbitrary
commands to a key in config.kdl, so a consent screen for the wasm beside it was
not buying anything -- but it does mean plugins/ is not a download folder.

packaging/checks/plugin-permissions-live.py drives both halves on a real
session: the shipped plugin must run without the prompt, and the SAME wasm
loaded from outside the plugin dir must still ask. Confirmed by disabling the
rule and watching the first half fail with the exact "asks permission to ...
Allow? (y/n)" screen it was written against.

1 files changed, 36 insertions, 0 deletions

diff --git a/docs/roadmap.md b/docs/roadmap.md
index 9afed17..ef71070 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -257,6 +257,42 @@ If it ever disagrees with the code, do not theorise about the screen: put a
 `/tmp/sl0ppij-$UID/sl0ppij-log/`. The server's own geometry settles in one run
 what screen-scraping cannot.
 
+## Fixed: the shipped plugins asked for permission on first launch
+
+pane-finder requests three permissions as it loads, so the first press of its
+keybinding on any new machine opened a consent screen instead of a fuzzy finder
+-- a nag about our own software, on a binding we ship.
+
+Plugins we ship are now granted implicitly: builtins (via the existing
+`PluginConfig::is_builtin`, the same predicate `check_command_permission`
+already uses) and any wasm inside a plugin directory we install into -- the
+config dir's `plugins/` and the data dir's `plugins/`. The rule is
+`plugin_is_shipped_with_sl0ppi` in `zellij-utils/src/input/permission.rs`, and
+it is deliberately narrow:
+
+- the same wasm from any other path still prompts;
+- remote plugins are never trusted;
+- paths are normalised lexically first, so `plugins/../../evil.wasm` is not
+  "inside" the plugin dir;
+- the trusted directories are derived from the environment and the default
+  locations, so getting them wrong costs a prompt and can never grant one
+  somewhere else.
+
+The trade is that `<config dir>/plugins/` is now a trusted directory, documented
+in `config/README.md`: anything that can write there can already put arbitrary
+commands on a keybinding in `config.kdl`.
+
+**How to re-run the check**:
+
+```bash
+make check-live      # includes packaging/checks/plugin-permissions-live.py
+```
+
+It launches the real pane-finder wasm from a temp config dir and asserts it
+runs without the prompt, then launches the *same file* from outside that dir and
+asserts it still asks. Confirmed by disabling the rule and watching the first
+half fail with the exact "asks permission to ... Allow? (y/n)" screen.
+
 ## Standing risks
 
 **`sl0ppij/target` is a symlink to `~/lol/zellij/target`.** Introduced when the