docs: document the plugin marketplace (#1805)

* docs: document the plugin marketplace

Add a public Plugin Marketplace page covering both audiences: operators
using the in-app catalog (Browse/Installed tabs, one-click install,
Update to vX, the Sources dialog for team/corporate registries, plugin
icons, feature-flag gating, sideloading still works) and plugin authors
publishing into it (one-repo-per-plugin GitHub Release assets, the
optional manifest icon field, submitting a plugins.yaml PR to the
official catalog, GitHub-stars-only ranking, and hosting your own
index.json source).

Also cross-link the new page from plugins.md (replacing the now-false
"No plugin marketplace" security note), plugins-authoring.md, and
plugins-manifest.md (new icon field row); register it in meta.json and
coverage.json.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs: correct plugin-registry CI validation claims

The registry index-build workflow does not validate plugins.yaml against
schema.json, nor does build-index.mjs compare the entry id to the
manifest id — bad entries are skipped-and-logged, and CI only fails when
a non-empty list resolves to zero built entries. Reword the submission
steps (in both the marketplace docs page and plugin-registry/README.md)
to describe what the workflow actually does: it resolves each entry
against the GitHub API and requires a correctly named
<id>-<version>.tar.gz release asset, with maintainer approval as the real
gate. Also clarify that plugins.yaml `categories` are free-form curation
tags, not the manifest's category enum.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* ci: split plugin-registry Pages deploy into its own job

The single build-and-deploy job bound the `github-pages` environment at
the job level, so GitHub evaluated that environment's protection rules on
every PR run — failing the check even though the deploy steps were gated
to non-PR events. This broke every PR touching plugin-registry/**, which
is exactly what a plugin-submission PR does.

Split into a PR-safe `build` job (no environment) and a non-PR-gated
`deploy` job that owns the `github-pages` environment and runs only
`deploy-pages`. Behavior on push/schedule/workflow_call is unchanged; PRs
now run build+tests without tripping the environment gate. The star
refresh calls this workflow by file path, so the job rename is safe.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs: describe index-build asset resolution accurately

build-index.mjs picks the <id>-<version>.tar.gz release asset when
present but falls back to the release's first .tar.gz otherwise, and only
errors when a release has no .tar.gz at all — it does not hard-fail a
misnamed asset. Reword the submission steps to present the exact asset
name as an authoring instruction (so the index resolves the right asset)
rather than a builder-enforced gate.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Revert "ci: split plugin-registry Pages deploy into its own job"

This reverts commit 2c5f649146.

* Reapply "ci: split plugin-registry Pages deploy into its own job"

This reverts commit 3795cdb98a.

---------

Co-authored-by: Kandev Agent <agent@kandev.dev>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.github/workflows/plugin-registry-index.yml

@@ -12,8 +12,8 @@ on:
     paths:
       - "plugin-registry/**"
       - ".github/workflows/plugin-registry-index.yml"
-  # Validate registry edits before merge (build + test run; the Pages deploy
-  # steps below are gated to non-PR events, so a PR never deploys).
+  # Validate registry edits before merge (the build job runs; the separate
+  # deploy job is gated to non-PR events, so a PR never deploys to Pages).
   pull_request:
     paths:
       - "plugin-registry/**"
@@ -39,12 +39,13 @@ concurrency:
   cancel-in-progress: false
 
 jobs:
-  build-and-deploy:
-    name: Build index.json and deploy to Pages
+  # Build the catalog and, on non-PR events, stage it as a Pages artifact.
+  # Kept free of the `github-pages` environment so it runs on PRs — a job that
+  # binds that environment is checked against its protection rules even when its
+  # deploy steps are skipped, which fails every PR that touches plugin-registry/.
+  build:
+    name: Build index.json
     runs-on: ubuntu-latest
-    environment:
-      name: github-pages
-      url: ${{ steps.deploy.outputs.page_url }}
     steps:
       - name: Checkout code
         uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6
@@ -85,7 +86,18 @@ jobs:
         with:
           path: _site
 
+  # Deploy the staged artifact to GitHub Pages. Separate job so the
+  # `github-pages` environment (and its protection rules) is only ever
+  # evaluated on non-PR events.
+  deploy:
+    name: Deploy to Pages
+    if: github.event_name != 'pull_request'
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: github-pages
+      url: ${{ steps.deploy.outputs.page_url }}
+    steps:
       - name: Deploy to GitHub Pages
         id: deploy
-        if: github.event_name != 'pull_request'
         uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4