plugin-catalog: delist tabro; add rule 17 (no unscannable executable payloads)

tabro bundles a prebuilt Windows .exe (relay-native-host-0.4.2.exe) in its
plugin tree. The install scanner cannot read machine code, and the SHA-256 the
plugin checks it against is committed in the same commit, so it only proves the
file was not changed after that commit, not where it came from. A reviewer
cannot tell it matches the in-repo C++ source. That is a precedent worth
closing before someone ships a binary that is not benign.

- Delists tabro (deletes plugin-catalog/tabro.yaml). Existing installs keep
  working; not added to removed.yaml — there is no evidence of malice, only no
  way to verify the binary. An attested build (rule 17) is the way back.
- Adds admission rule 17: no compiled binaries, committed Python bytecode, or
  archives hiding either, detected by file header not extension. A native
  component is allowed only with a GitHub build-provenance attestation tying it
  to the plugin repo's own workflow at the pinned commit; a setup-time download
  is allowed only from the tool's official source, pinned by checksum and
  disclosed. Mirrored into the docs submission guide (the mirror test enforces
  identical text).

A full-content scan of all 543 pinned entries found tabro is the only one with
a native executable. The enforcing gate ships in a follow-up PR.

plugin-catalog/README.md

@@ -118,6 +118,25 @@ meaningful:
    go upstream as a PR to its author. A fork that renames, rebrands or adds small
    changes is declined in favour of the original. A listed fork names its origin
    in its disclosure line (`Derived from <entry>`).
+17. **No unscannable executable payloads.** Everything a reviewer and the
+   install scanner read at the pinned commit must be source they can read. A
+   plugin must not ship a compiled binary (a native executable or library of
+   any OS — detected by file header, not extension: ELF, Mach-O, PE/`MZ`,
+   WebAssembly), committed Python bytecode (`.pyc`/`.pyo`, including sourceless
+   or hash-forged caches that run instead of the `.py` beside them), or an
+   archive whose members are not themselves reviewable source. A plain-text
+   source bundle (a `.tar.gz` of `.py`/`.ts`/`.md` the plugin unpacks) is read
+   like any other source; a bundle hiding a binary is not. The scanner cannot
+   read machine code, and a checksum committed in the same commit only proves
+   the file was not changed after that commit, not where it came from. If a
+   plugin genuinely needs a native component, the binary must be built by the
+   plugin repository's own public GitHub Actions from source in that repository
+   and carry a GitHub build attestation (`actions/attest-build-provenance`) tying
+   it to that workflow and commit; the gate verifies the attestation against the
+   pinned commit (`gh attestation verify --repo <owner/repo> --source-digest
+   <pinned sha>`). A binary a user's own machine fetches at setup time is allowed
+   only from the upstream tool's official source, pinned by checksum, and
+   disclosed (rule 13) — never bundled and never from an unofficial mirror.
 <!-- admission-rules:end -->
 
 The step-by-step submission guide, with the same rules and what reviewers check,

plugin-catalog/tabro.yaml

@@ -1,17 +0,0 @@
-name: tabro
-repo: https://github.com/ohmyskyhigh/tabro
-sha: 6b0b7e526cb6d85dc3fb3d0eae63d051b5be127a
-subdir: integrations/hermes
-description: "Chromium profiles (Chrome, Chromium or Edge 153+) and session-owned workspaces through 22 MCP tools, with authenticated HTTP(S)/SOCKS5 proxies. Includes the Windows runtime; set TABRO_BROWSER_PATH to the browser before installation. Disclosure — Windows-only; requires TABRO_BROWSER_PATH pointing at Chrome, Chromium or Edge 153+; setup downloads a hash-pinned Node from nodejs.org, installs a Broker, browser extension and native host under %LOCALAPPDATA%\\Tabro (or TABRO_INSTALL_ROOT), registers HKCU Native Messaging hosts (Chrome, Edge, Chromium, AdsPower SunBrowser) and starts a detached background Broker on loopback that outlives Hermes; broker-owned browsers run with a loopback remote-debugging port while open; the model gets raw CDP (script evaluation, screenshots, input, response bodies) on signed-in browser profiles including user-owned ones, can route broker-owned profiles through proxies it names, and exit-IP checks contact api.ipify.org; payload is prebuilt bundled JS plus a native .exe built from in-repo source."
-maintainer: ohmyskyhigh
-tier: community
-category: web
-version: "0.4.2"
-platforms: [windows]
-docs_url: https://github.com/ohmyskyhigh/tabro/blob/6b0b7e526cb6d85dc3fb3d0eae63d051b5be127a/integrations/hermes/README.md
-readme: true
-capabilities:
-  provides_tools: []
-  provides_hooks: []
-  provides_middleware: []
-  requires_env: []

website/docs/developer-guide/plugins/catalog-submission.md

@@ -176,6 +176,25 @@ the gallery. There is no separate listing to maintain.
    go upstream as a PR to its author. A fork that renames, rebrands or adds small
    changes is declined in favour of the original. A listed fork names its origin
    in its disclosure line (`Derived from <entry>`).
+17. **No unscannable executable payloads.** Everything a reviewer and the
+   install scanner read at the pinned commit must be source they can read. A
+   plugin must not ship a compiled binary (a native executable or library of
+   any OS — detected by file header, not extension: ELF, Mach-O, PE/`MZ`,
+   WebAssembly), committed Python bytecode (`.pyc`/`.pyo`, including sourceless
+   or hash-forged caches that run instead of the `.py` beside them), or an
+   archive whose members are not themselves reviewable source. A plain-text
+   source bundle (a `.tar.gz` of `.py`/`.ts`/`.md` the plugin unpacks) is read
+   like any other source; a bundle hiding a binary is not. The scanner cannot
+   read machine code, and a checksum committed in the same commit only proves
+   the file was not changed after that commit, not where it came from. If a
+   plugin genuinely needs a native component, the binary must be built by the
+   plugin repository's own public GitHub Actions from source in that repository
+   and carry a GitHub build attestation (`actions/attest-build-provenance`) tying
+   it to that workflow and commit; the gate verifies the attestation against the
+   pinned commit (`gh attestation verify --repo <owner/repo> --source-digest
+   <pinned sha>`). A binary a user's own machine fetches at setup time is allowed
+   only from the upstream tool's official source, pinned by checksum, and
+   disclosed (rule 13) — never bundled and never from an unofficial mirror.
 <!-- admission-rules:end -->
 
 ## Updating your entry