record where the member story actually stands

The platform now has `scope: 'shared'` for a dependency every account must be able to run, and the
check that goes with it — world-executable, and every parent directory traversable.

iris cannot use it yet, for a reason worth writing down rather than rediscovering: it BUILDS its
binary in the sidecar rather than declaring it as a dependency, so there is nothing for the probe to
judge. The remaining half is this sidecar installing into /usr/local/bin.

Also corrected open item 3, which said a member's agent "cannot read it there". On alpha it can —
/home/<owner> is mode 751, so an absolute path traverses. That is an accident, not a design, and 750
would break it silently. Stated that way so nobody concludes it already works.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

PLUGIN.md

@@ -55,8 +55,12 @@ This contract predates the desktop plugin. When that plugin lands, this path is
    own ephemeral one. Both are written; neither is proven. Also unproven: that a seeded cookie copy is
    accepted (Chrome ties cookie encryption to `Local State`, which is copied for exactly that reason).
 3. **Members.** The wrapper isolates per-user by `$HOME`, but the binary lands in the *owner's*
-   `~/.local/bin`, and a confined member's agent cannot read it there. If members should capture,
-   the binary needs a shared home. Deferred until the desktop plugin defines the member story.
+   `~/.local/bin`, and a confined member's agent cannot reliably reach it there — on alpha it happens to
+   work only because `/home/<owner>` is mode 751, and 750 would break it with nothing reporting so.
+   The platform now has the vocabulary for this (`scope: 'shared'` on an osDependency —
+   `docs/plugin-dependency-scope.md`), but iris builds its binary rather than declaring it as a
+   dependency, so the remaining half is this sidecar installing into `/usr/local/bin` instead. Deferred
+   until the desktop plugin defines the member story; until then iris is owner-only in practice.
 4. **Cookie copy under a live browser.** Copying a SQLite file mid-write can catch a torn state. Being
    WAL does not make this safe — it is what makes the copy INCOMPLETE, because a recent write may live
    only in `Cookies-wal` until the browser checkpoints it. This originally read "the cookie DB is WAL and

manifest.ts

@@ -47,6 +47,8 @@ export const manifest: PluginManifest = {
 
   osDependencies: [
     {
+      // Owner-scoped: cargo is the BUILDER, run once by this sidecar as the owner. Members never invoke
+      // it. What they need is the binary it produces — see the iris entry below.
       binary: 'cargo',
       reason:
         'Builds the iris screenshot binary from source, once, on first start. Nothing works without the build. ' +